[Matroska-devel] New elements

[Christian HJ Wiesner]

Steve Lhomme wrote:

> Hi,
> As it was requested, it would be nice to have sample-accurate seeking 
> in Matroska (for audio-only files). Therefore I added 2 elements to 
> support that in the specs (as well as version 1 of the specs).
> SampleScale is a scale factor for the BlockSamples element
> BlockSamples is the actual count of samples since the beggining 
> (timecode 0), but this value is scaled :
> SampleScale * BlockSamples = actual number of samples since timecode 0.
> I'm going to add support for this in libmatroska right now.


Not so quickly please Steve !

Its ESSENTIAL that we are 100% sure about what we are doing here. Have 
we thought about :

- inaccurate sampling rates, like 44055 Hz, as caused by inferior 
soundcards doing live recordings ? For the time being, many analog 
capture fans convert from AVI/MPEG to matroska, because our container 
will keep sync in any case, while the sample rate based containers fail 
very often on keeping sync for analog capturing, especially with bad 
soundcards

- if a player, say its foobar2000, wants to do gapless playback of 
multiple MKA tracks in its playlist, and the file it has to play was 
made with VirtualdubMod or the matroska muxer on DirectShow for example, 
we cant have that because your new elements are not supported in the old 
files. Thats sucks ! In short, there will be some files that play 
gapless, some wont. And as our specs will *always* allow both ways to 
make MKA files, the users will never be able to trust that gapless MKA 
playback works.
Have we really investigated *ALL* possibilities to make sample accurate 
seeking possible with any MKA file, even with a lower timecode accuracy 
? What about putting some intelligence into the players here ?

- if you are using special timecode scaling for every single track in a 
matroska file, depending on its sampling rate, and lets say the file has 
5 or more tracks, wont it be pretty complicated and CPU intensive to 
parse these matroska files ? Dont forget, our matroska splitter will 
expose all audio streams on DirectShow, and its up to the 
player/switcher to select one of them, but still *ALL* tracks are parsed 
in the parser filter.

- accurate video editing with PCM sound might require to cut *exactly* 
the right PCM sample at the end of a video frame. If both tracks have 
the same timescale, thats no problem at all. If you start using 
different scales for each track, things might get complicated. You might 
find yourself in a situation where a specific PCM sample is added to 
both halfs of the splitted movie, and when these parts are concatenated 
again you are loosing sync ( ok, its only one sample ) because of the 
repeated sample.

Please, lets not hurry this ..... we have to find a good solution, with 
respect to all existing aspects of the problem

Christian