Topic

I've tried saving/opening a few files and it seems to work nicely.

Just Wondering if it is safe (want to use Matroska because of error correction in case I want to burn the content on a CD in Mode2 (XCD)

Thanks

I think there is no problem in including WM9 in mkv. It is supposed to be a container format supporting almost all new codecs.

Yes, it is safe and it has been safe now for quite some time. As for the error correction I do not believe matroska actually has any. It has CRC error detection but this will _not_ correct anything. But it is helpful, I mean it would take a lot more room to actually add error correction into the file and then that would defeat the purpose of XCD. CRC will just skip the errors so your file will keep playing, at least I think this is what happens. Feel free to correct me if this is wrong.

Flexible error correction ( ECC ) on the file level is still on our to-do list, error detection ( EDC ) is working fine already ...

myths and reality

crc/edc isnt used during playback of xcd atm (no matter what container you use): http://forum.doom9.org/showthread.php?s=&t...&threadid=63047

error correction is already possible with mpeg-4 streams: http://forum.doom9.org/showthread.php?s=&t...&threadid=65646

Unfortunately Xvid and DivX don't support that. Somebody should force the developers to add support for these mechanisms. :-)

Thanks for the replies. I'll stick with .avi for now.

You should consider using ogm or Matroska while they have basic error detection which is handy when your disc is scratched. Avi doesn't even have error detection and that might screw up your picture when there is an error inside some frame. Ogm and Matroska can skip these frames you might not even notice that there is a problem with the disc.

Ps. Please correct me if I'm wrong.

latexxx, plz read my post (and the link i pointed to) again

bond : crap

EDC ist used during playbck currently, simply because of the fact that we dont know what errors a decoder can handle, and what errors might crash him, so we dont use it at all. Having said that, it would be trivial to add in matroskasplitter.

As for ECC, we couldnt activate that by default for playback in the splitter, as weaker CPUs might be unable to invest the necessary extra processing power to allow ECC during playback, in real time, so we had to make it an option, if if we implement it at all.

The bigger use for ECC in the file, IMHO, would be to be able to repair damaged files, using an offline tool .....

a guy from your team told me that the crc in matroska isnt used during playback
yes, it was the one, who once wrote a xcd faq on doom9


edit: and if you write it would be easy to add to the matroskasplitter, this means that it isnt added atm for me too

... again, there is no sense addit it.

If you detect via CRC32 ( EDC ) that a block is broken, what do you do with it ? Do you discard it ? Do you pass it to the codec ?

As long as there is no clear strategy - and separately for each codec - what to do with a block when you detect the CRC32 doesnt match, there is no sense implementing it. And this is valid for ANY general use container, that can take several different audio/video codecs .....

we need to get alexnoe to answer this here

to sum up what he said to me:
1) the XCD already has the CRC feature (another CRC from the container doesnt tell us anything new -> CRC on the container is useless if the XCD-CRC is used)
2) The container-splitter does the container-CRC checking and therefore should avoid passing the broken parts to the decoder
(as you said yourself the matroska splitter currently doesnt do that, which means that the matroska CRC is useless cause it isnt used anyways...)

the same goes for other containers (OGM) too of course

Noooo !! Dont you see that this is plain wrong ?

If the CRC32 check fails, all you know is that something in the block has been changed. Unfortunately, CRC32 wont tell you HOW MUCH has changed, so in the end it may be a single bit only, causing no damage at all to the decoder !!

So because of that, in many cases it may be a much better solution to pass the data to the decoder even IF the CRC check has failed, because otherwise you may have to skip a part of say 1000 frames, and without any necessity, because you are no passing an important I frame to the decoder because of a single bit, making the following 1000 P/B frames redundant !!

Again, depending on the codec and its sensitivity to corrupted data, a decision has to be done if packets where CRC failed had to be passed or not. A general assumption to not pass those data is not correct. In fact, i loved to talk to codec developers more on this issue, as they might know best how good ( or bad ) their codecs will behave, and if they prefer to get bad blocks in any case, or not ....

There is some weird stuff in your post:
First, you can easily crash divx 3.11 by flipping one bit (i did that some time ago when I memory stick was b0rked in my system), second, one- and two-bit-errors can be detected by CRC and can be recognised (it's kinda hackish, but you can check if exactly one bit was broken, or if it was more)

Second, if you really want to add a CRC to each block, causing 6 bytes of overhead, the overhead will be far more than of any AVI file, maybe even worse than OMG.

Third, the CRC on X-CD level is formed over each 2324 bytes, which is often smaller than one block, so that you cannot lose more than 2 blocks with one b0rked sector anyway. If you then take the frame interleaving on sector level into account, it is highly unlikely that one, and only one, sector gets b0rked.... so the harm caused by a damaged area on a CD will be very similar, whether or not there is a container CRC, if the XCD filter would use the CRC on the CD itself. Also, this interleaving on frame level makes sure that wrongly read bytes will be nicely spreaded, and not concentrated on one small piece within one sector. I.e. if a sector spans over 2 blocks, and this sector gets b0rked, both blocks are screwed up anyway.

And don't even dream about DVDs. You cannot get any b0rked data from a DVD; you rather get a read error and lose at least 2 kb (or even 32 kb, if an entire ECC block is screwed; i actually don't even know if you can lose anything smaller than one 32 kb ECC block). Usually, the file system of windows b0rks then....so your nice CRC won't help much either

Summary :

Alex recommends to save the CRC elements from the matroska/OGM/MP4 files, because they are of no use at all, and to rely on the CRC/ECC of the transport layer, means CD or DVD .....