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

Joël Bourquard numlock at freesurf.ch
Sun Nov 16 23:47:24 CET 2003

Thank you Christian for making this "meeting minutes".

Here's some personal thoughts:

I trust Frank when he says Musepack's strength is in the psymodel, but
regardless of quality concerns, I still think it would be preferable to
include the current subband format in SV8.

Some reasons:
- Speed (ok, Huffman codes take some effort to decode, but MDCT is by
far the most expensive process). Optimizations to Huffman decoding can
be done, while MDCT is kind of irreductible.
- Flexibility (just imagine a single bitstream with an "efficiency" MDCT
and a "speed" subband mode..  both produced using the same psymodel
!)..  so all devices can be targeted.
- Compatibility (the cleanest way to re-use our current SV7 files, will
be to make them SV8-convertible !)

Since the framing structure is cleaner in SV8, complexity should not be
a problem (the only additional work is in a lossless SV7->SV8
converter). I guess the inter-frame limitations can be sorted out during
SV7->SV8 conversion.

Sincerely I don't see the point in SV7.5. Creating yet another
fileformat isn't going to help, I think. Plus it would slow down the
development of stream processing tools, wouldn't it ?

So why not create a simple, straightforward, flexible standard which
handles both subband (for compatibility and speed) and future MDCT data

I don't know much about AC3, but it looks like a very interesting idea.
Well, if the psymodel is good and open, almost anything can be done with
it !

I hope my statements are not too messy (I'm a bit tired..)

Cheers !

On Sun, 2003-11-16 at 11:19, Christian HJ Wiesner wrote:
> 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.
> Christian
> MPC and matroska project admin
> http://mpc.corecodec.org

More information about the Matroska-devel mailing list