Donation for Frank Klemm's new PC, The donation has ended Options

[ssamadhi97]

Frank, thank you very much for all the work you've done on MPC. It's greatly appreciated.

[CiTay]

Tonight i had a more than 3 hour phone conversation with Frank Klemm. We talked about many things, regarding the forum, the hardware for the PC, and of course about MPC. I hope i can recall most of it. We often switched topics so it may all sound somewhat disconnected. But he is a very nice person to talk with and not one bit arrogant.

He told me why he rarely visits web forums. He always used Newsgroups. He prefers the idea of offline storing, post scoring, filtering, thread selection, fast local search and the speed in which he can comb through new posts in NGs. For forums, he is too used to his workplace, where they have a big line and anything comes up in half a second. At home, he just has a modem. I offered that we could pay for a DSL line, but he prefers a modem. He says, with DSL, he would stay online too often and wouldn't focus on things like programming anymore. He handles all his bigger downloads at his workplace. Also, he doesn't really like how forum threads sometimes get off-topic really quick and you have to read a lot because you don't have much filtering features. It's more about preference towards newsgroups. But he said that he will see if he can visit HA more often.

Then we talked about short blocks and long blocks in MPC, AAC, MP3.. how an ideal audio format would have to look like. Then about P4 vs. Athlon 64, that it would probably be better to go the P4 route, because the Intel machines at his work were always rock stable, contrary to his previous Athlon system sometimes. Then other stuff that he became interested in now, like HDTV, how movie DVDs could be improved, interlaced vs. progressive playback, MPEG-2 vs. MPEG-4 vs. WMV9 etc., how TFT contrast measurements in c't are wrong, and how TFT need a much bigger screen resolution than there is now.

He also talked about his past as a LAME developer. When he started off programming on it, there were reports about a high frequency problem that they tried to fix for a long time, and he noticed a part where they used the ISO ATH which is about 50 dB wrong in that area, and he replaced it with his own measurements which were much more exact. The problem which they worked on before for decades was immediately fixed. Soon after that came complaints about bitrate going up. Then, the old code with which they tried to fix the bug before was never removed by them from the code, so there were workarounds for a bug that was fixed. The whole LAME code actually looked messy, different people used different tabulator spaces and so on. Also, it was hard to program some bigger things, because people would constantly update something, and his offline code was outdated when he finally wanted to upload. He often just hit delete then. Then were was something about a calculation for maximum possible bandwidth where there was much arguing about, for which he proposed an easy calculation which was rejected. Some time after that they removed his write access to CVS. A bit later, he found parts of his code with the copyright of other people below it. That's when he finally had enough with LAME.

After that, he moved on to MPC. He did speed optimizations for MPC with an old Pentium 166 or so, that didn't even have a soundcard, just decoding to /dev/null. As we know, he managed to improve de- and encoding speed considerably.

Then what you are probably waiting for. The current status of MPC. He said he will at the very least work on the current encoder again and make a final SV7 encoder. He will fix some remaining bugs he is aware of, like problems with file handling, and clean up the code.

About developing in general, there are some issues he traditionally had problems with. He can't do much coding for XMMS in Linux, he needs some people to help him with that, but i think Christian had an idea about that already. Then the project coordination isn't working too well. Sometimes with small issues, there is lots of feedback, but with bigger things, people are more quiet and then there is this issue again about forum/e-mail coordination. Also, he said that the current MPC website is a catastrophe. Sometimes he didn't release something because he didn't know what to update where anymore. I offered him to help him with the website so he can get new releases out without a hassle. Maybe somebody can come up with a good, clean template for the website.

This was basically it. MPC will go on. Depending on how good we can coordinate it and how good he can get into the code again, we could be able to see some more regular releases again. Thanks again to everyone who donated or will donate.

[spase]

I would be happy to help design a website with minimal graphics but still a good look and feel.

I don't know if I would have time to administer it though.

[chrisgeleven]

I am no longer a Musepack user due to finding that MP3's were just much more convient and easier to use the way my listening habits are. However, I have always been impressed with Musepack and loved the sound quality I got from it. I want to thank everyone who helped out Frank with getting him a new PC. I hope he is able to finish off SV7 and who knows what else will happen afterwards.

Didn't at one time it was announced that Frank was going to work on OGG? Maybe I am confusing him with someone else.

I am curious what Frank thinks of AAC as well.

[atici]

This might yet be the revival of MPC! And Frank has come back!. All this is so sentimental. Why not focus the new development at Project Musepack site ?

[BetaBoy]

This might yet be the revival of MPC! And Frank has come back!. All this is so sentimental. Why not focus the new development at Project Musepack site ?

Chris and I discussed this a while ago... don't worry ... Once we know Frank has started coding well get the CoreCodec.org Project page up speed in preperation for it.

[spase]

Are my services not needed then?

[c.b.2000]

People prefer others appreciation to loaves and fishes.

[lazka]

I hope Frank won't play much with his new pc:
otherwise we will find a "Frank Klemm's CS Clan Site" instead of a "Musepacksite"

(nice site but someone forgot the second 'f' in 'ofizielle')

[user]

nice to read some short & precise comments by Frank again

[dreamliner77]

This is the best codec news i've had in a long time.


Thanks Frank....

[alancienne]

A little donation for a great cause ...

[Lev]

I offered that we could pay for a DSL line, but he prefers a modem. He says, with DSL, he would stay online too often and wouldn't focus on things like programming anymore. He handles all his bigger downloads at his workplace.

Hah; exactly my mindset. I would only be distracted / feel I have to sort stuff out with high speed at home.

[AgentMil]

w00t good to see ur somewhat back Frank!!!

Glad to hear that some progress will be made in the near future...

Good luck with any future endeavours... hope my donations and many others has shown to you that we are actually a bunch of caring people.

BTW I am off for another holiday hehehe... enjoy hopefully within two weeks something new and interesting will be available to play with

If I do connect it will be from somewhere exotic .

Regards

AgentMil

[Frank Klemm]

I want to pass on the work on the XMMS Musepack plugin to someone else.
The task was initailly done by someone else, but the plugin was horrible out of date
so I updated the plugin/removed some bugs and problems in the plugin.
But I have no skills in programming GUI stuff. "no" has here the meaning of "zero".

- Version is 0.98
- The tagging stuff do not work at all (Note: there was never an edit box for the title number in it)
- Decoder is not fully optimized, but supports all newer features like replaygain, PNS, IS °)

The maintainer should:
- be a Linux Guru
- be responsible to maintain the code
- be responsible to help people concerning plugin development
- distributing code and compiled binary packages
- work should be done carefully, so I don't need to waste time to check the work

There is some optional addition work. For instance I had included EQ presets.
Currently there are four of them to equalizer four different headphones I have in usage.

Source files are around 400 KByte. Some code is taken from the encoder/decoder.
This code I would add to the package.

°) IS is not used by any encoder

[dev0]

The first person who came into my mind was TrnSZ, since AFAIK he has worked with the source before to make it compile on Mac OS X. He's not a Linux user/guru though, but I'm sure he'd do a great job at maintaining it anyway.

dev0

[goweropolis]

What about xmixahlx? He maintains the Debian Rarewares site.

[ChristianHJW]

The maintainer should:
- be a Linux Guru
- be responsible to maintain the code
- be responsible to help people concerning plugin development
- distributing code and compiled binary packages
- work should be done carefully, so I don't need to waste time to check the work

I will try to get the project more organized in future. MPC will become one of the many opensource projects around, and we will use the means of great software that was made exactly for this reason, the sourceforge Alexandria/Savannah/GForge platform on corecodec.org.

As a start i uploaded all the known sourcecode, ie. the lastest decoder sources from Case ( mppdec 1.95 z67 ), the SV8 alpha encoder and the ARM decoder sources to the CVS on http://corecodec.org/projects/mpc . You cant browse the source tree using the webinterface on corecodec right now ( dont know whats wrong, seems to be a phyton problem ) but anynymous CVS checkout works fine, as well as committing/checkout for team members.

I will define a task on cc.org about maintaining the XMMS plugin, and ask Frank for the sourcecode of it, so i can upload it also. Whoever is interested on working on it, register on corecodec.org and contact me via email to chris AT matroska.org, so we can make a decision here. I cant help coding, but sometimes a little bit of organisation help can make a big difference for a developer i learned .....

[dev0]

Be sure to include the sources of foobar's MPC decoder (it's in SDK.zip), since DEATH optimized seeking a lot recently.

dev0

[Frank Klemm]

I'm (actually the MODEM) is transmitting the current source ball of SV7 and SV8 to Christian.
This contains the encoder and decoder of the current SV7 stable tree and the SV7.5/8
experimental tree.

The SV8 encoder and decoder do not compile, there are some source files missing, which
must be computer generated (Huffman Tables).

BTW there is really no mystic things on the encoder. Source is much shorter and simplier
than that of Lame. Most of the stuff is straight forward.

BTW2: There is an assembler file in the encoder, but the code is far from being ready and the
code was never used. Encoder is pure C. No C++ and no Assembly code.

[NumLOCK]

Wow, this is all great news !

I've always thought that Musepack had its place in high quality codecs.. now if development continues (in SV7 at least), that is great !!

For Frank:
Congratulations on your new PC

Some food for thought:
I know this doesn't matter for SV7, but I've been working on a fast entropy coder which is very easy to use. I haven't released its source code, but if SV8 is still planned, I'd be glad to donate it for usage in Musepack. It is short and concise.

Basically, you input a stream of bits with probability estimate for each bit, and it outputs a compressed stream. Isn't this user friendly

There is some flexibility, by switching between 8/16/32bit modes:

CODE

one-time overhead (unpredictable) Max bytes compressed into 1 bit (approx)
     0..8 bits                                   32
     0..16 bits                                 8k
     0..32 bits                                 512M

Best-case is when the estimates are exact (ie: never), then after the one-time overhead, each 512MB chunk will only add 1 bit of output

Compression is great for black and white images. In general it is excellent when there are many zeros, or when the probability of a bit value (for example 0) is greater than 75% for example.

The current throughput (on P3-866 with PC133) is already decent (more than 10MBits/s). It's quite the same in the 3 operation modes.

Edit: In current SV8 Musepack, are the lossless and lossy parts dependant of each other? maybe yes? (if yes, that would make my coder quite useless for MPC right?)

Edit 2: In better words, I wondered if SV8's quantization noise is produced in the entropy coding stage or not.

This post has been edited by NumLOCK: Feb 17 2004, 23:30

[seanyseansean]

Edit 2:  In better words, I wondered if SV8's quantization noise is produced in the entropy coding stage or not.

Eh? I don't understand how the quantization noise could be produced in the entropy coding stage. Am I reading your question wrong?

It might be a good idea for some nice dev to split this code related discussion into a new thread maybe?

sean

[seanyseansean]

I'm (actually the MODEM) is transmitting the current source ball of SV7 and SV8 to Christian.
This contains the encoder and decoder of the current SV7 stable tree and the SV7.5/8
experimental tree.

Hi Frank, nice to see you around again.

Can I make this clear - are you transmitting the sv7 encoder source to Christian for public (CVS) access?

[NumLOCK]

Edit 2:  In better words, I wondered if SV8's quantization noise is produced in the entropy coding stage or not.

Eh? I don't understand how the quantization noise could be produced in the entropy coding stage. Am I reading your question wrong?

sean

Um, yeah.. after a glance at the SV8 specs (last itme I looked), it seems that the encoder chooses a clever value of N, then groups N subband samples into one chunk, and then uses an entropy coding that's specific (ie: optimized) for that chosen value of N.

Perhaps I should read it again.

It might be a good idea for some nice dev to split this code related discussion into a new thread maybe?

Right. Sorry about sliding off-topic..

Edit: Cleared up things.

This post has been edited by NumLOCK: Feb 18 2004, 00:46

[ChristianHJW]

I'm (actually the MODEM) is transmitting the current source ball of SV7 and SV8 to Christian.
This contains the encoder and decoder of the current SV7 stable tree and the SV7.5/8
experimental tree.

Hi Frank, nice to see you around again.

Can I make this clear - are you transmitting the sv7 encoder source to Christian for public (CVS) access?

Hmmm ..... probably, but then maybe without a standard license ? In this case the normal copyright laws apply to the code, so it can be viewed but not used ? I will double check with Frank about his intentions here ....