SV7 to SV 8 conversion for matroska integration : call for opinions

Hi,

please use the 'reply all' button of your mail client when replying, so 
all lists get copied.

Frank convinced us that using SV7 in matroska is maybe not a good idea. 
Therefore the matroska team was discussing a couple of options today 
about MPC integration into matroska :

1. Wait for Frank to write a SV7 to SV8 'repacker' tool. This would 
slightly increa'se overhead, but this way old existing SV7 files could 
be packed into matroska, and all existing encoders could be used for 
movie soundtrack encoding

2. Make an encoder filter for DirectShow or a little CLI app with 
libmatroska based on Frank's 'alpha' SV8 encoder, which seems to be 
quite usable and according to Frank was tuned to overcome some reported 
sound limitations in the existing SV7 encoder. We could tag the current, 
'alpha SV8 bitstream' as SV 7.2 , SV 7.5 or even SV8, and write the 
blocks directly into matroska files, stripping even the block size from 
the SV8 alpha bitstream to become as independant as possible from future 
bitstream changes. The chances are good that these files would be 100% 
SV8 compatible. If not, we could tag them differently, or convince Frank 
to make SV9 instead of SV8 ;-) ....

3. matroska has a very powerful and complex lacing and frame handling 
system, allowing us to even mux SV7 streams into matroska files, without 
breaking the specs. For this case we could put 32 MPC frames into a 
single matroska block and use either the enhanced EBML lacing or the 
so-called time-slices, allowing us to group a complete 'self-decodable' 
group of blocks into one matroska block. That way we even dont care if 
single bits of one frame are attached to other frames, as they form an 
entity in the matroska file.

I would like to hear your opinions on that. Everybody is clearly invited 
to tell us his personal opinion about this, even if its not technically 
founded.

Best regards

Christian