[Matroska-devel] Protocol of my 2+ hrs telephone conversation with Frank Klemm

Christian HJ Wiesner chris at matroska.org
Sun Nov 16 11:19:18 CET 2003

I want to give a short summary of this long telephone conversation, here 
the topics we discussed :

1. Subband coding vs. Transformation coding
2. Future of MPC
3. MPC in matroska
4. DVD players and their problems

1. I was very surprised to understand that Frank doesnt see any benefit 
in musepack's subband coding, compared to modern transformation codecs 
like AAC or even Vorbis. He told me that musepack's results in the 128 
kbps listening test are a slap in the face of the other codecs, as 
normally musepack should have performed worst at this bitrate. He is of 
the opinion that musepack's only advantage is the psy model he made, or 
the lack of there-of in the other codecs.
Not even in the decoding speed does he see a big advantage in subband 
coding, he is convinced all of the other decoders could be optimized a 
lot, especially with improvements in the lookup of the huffman tables, 
with a proper indexing system as he has done with musepack once, gaining 
a speed advantage of factor 9 compared to buschel's code.
He mentioned more than one time that MP3, from his point of view, is not 
at all well specified and implemented and can even lead to drop-outs 
during playback under certain conditions. He sees AC3 as a very good 
standard for his needs, because of well existing hardware decoders in 
external receivers, a proper and well done specification and 
implementation, and because with DVD burners beoming more and more 
popular, low bitrates for audio compression will be only interesting for 
streaming in future, and he doesnt see the big market for streaming at 
all. He told me he is maybe interested in making a proper AC3 encoder, 
using his own psy model, that in principal can be transferred from one 
encoder to another.

2. It seems that Frank is more and more into video, especially DVD 
video, and my personal opinion is that musepack is not in the center of 
his interest anymore. His opinion on 1. surprised me a lot, i didnt 
understand why he had invested so much time into musepack when subband 
coding has no advantages compared to other coding technologies, but as 
so many other technicians i guess it was more like a prrof of concept 
for him, after the LAME people had more or less pushed him out of the 
team because of the many radical changes he had in mind.
After learning that, i honestly question the future of musepack in its 
current form. It was maybe a better idea to make a good, free and 
opensource AAC encoder, or to fork from Vorbis and making a new 
compression format, if Frank ever finds the motivation again to invest 
serious work into making a new audio codec. The other alternative is, 
and that is what Frank obviously had in mind for musepack also, make a 
clear cut with subband coding for the future and make SV8 a 
transformation codec also. Frank told me that in his opinion the AAC 
standard has a couple of quirks in it, and we could maybe make a new 
compression format, still call it musepack and MPC, overcoming those 
problems, but on the other hand staying decoder compatible with AAC ??

It appears to me that Frank alone can not invest the time necessary to 
realize MPC SV8. On the other hand he could very well make the specs, 
and invest time into his main area of excellence, the psy model. He 
mentioned to me that he had invested too much time already into 
explaining what has to be done to other people, but without any real 
feedback from them after that. I offered to him to try to use the 
existing GForge/Alexandria facilities on the corecodec.org server for 
that,  allowing you to assign tasks, explain them one time,  and then 
let me search for a developer who wanted to care about that. I am not 
sure if i could convince him that this is a sensible thing to do, but he 
promised to make a last attempt here and compile a list of things where 
he could use help from outside. I will take this list and define taks on 
corecodec.org for each of them. Hopefully that way we can organize 
things a bit better in future.

3. Frank has doubts if our developers, mainly Toff, have really found a 
way to read a complete block of data from a SV7 file for muxing into 
matroska. He says the current bitstream is weired, there are sometimes 
bits from one block attached to the next or to the preceding block, so 
without calling the decoder on the blocks there is no way of finding 
out. Even then, proper seeking might be impossible because in worst case 
the decoding of a block can depend on up to 32 blocks before this block.
He promised to look into a repacking app, reading SV7, unpack the data 
and repack them into SV8 bitstream, forming a kind of SV 7.5 version if 
you want, as i convinced him there is no use of allowing subband coding 
in SV8 at all, if he feels it doesnt have any advantages to 
transformation encoding. With this app we could pack SV7 files into 
matroska fine, just a new decoder is necessary that can handle the new 
byte order as specified for SV8 ( big endian ).

4. Frank has a lot of ideas about improving currently existing DVD 
playback chains, like by implementing the video decoder chip into the 
TV, transferring the compressed video data from the DVD player to the TV 
via firewire IEE 1394 . He also believes it should be possible to delay 
the picture by several milliseconds, to allow the use of digitally phase 
corrected speakers, introducing a delay by deafult.

Conclusion :

MPC is not dead, not at all. Even in its current form, its a great 
encoder for movie soundtracks if highest quality for Stereo tracks is 
the aim, and Frank promised to look into a way to be able to get clear 
block boundaries for SV7 streams. The huge fangroup on HA.org, all music 
lovers compressing their music albums with it, are a good prrof for 
that. However, it seems that MPC only has a future in a complete new 
form, and the man who could bring the format there doesnt have the time 
to make this alone. IMHO its time to bring the project to corecodec.org 
now and use the existing opensource facilities more evident. The way 
things did work out until today, one man doing all the core things and 
the other devs implementing these core elements into several apps, will 
not work out for the 'new' MPC SV8 anymore.

Its time for us to ask ourselves if we want musepack to evolve further, 
or if we are happy with what it is today. Whilst it is usable for music 
compression already, its not for use with video. If we want musepack to 
progress, we all have to work together to improve it. Looking forward to 
hear your comments.

MPC and matroska project admin

More information about the Matroska-devel mailing list