Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WM9VCM in .MKV safe? (Read 6919 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WM9VCM in .MKV safe?

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

WM9VCM in .MKV safe?

Reply #1
I think there is no problem in including WM9 in mkv. It is supposed to be a container format  supporting almost all new codecs.
THE LAST AAC ENTHUSIAST[2.0 & 5.1]

WM9VCM in .MKV safe?

Reply #2
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.

WM9VCM in .MKV safe?

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


WM9VCM in .MKV safe?

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

WM9VCM in .MKV safe?

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

WM9VCM in .MKV safe?

Reply #7
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.

WM9VCM in .MKV safe?

Reply #8
latexxx, plz read my post (and the link i pointed to) again
I know, that I know nothing (Socrates)

WM9VCM in .MKV safe?

Reply #9
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 .....

WM9VCM in .MKV safe?

Reply #10
 

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
I know, that I know nothing (Socrates)

WM9VCM in .MKV safe?

Reply #11
Quote
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 .....

WM9VCM in .MKV safe?

Reply #12
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
I know, that I know nothing (Socrates)

WM9VCM in .MKV safe?

Reply #13
Quote
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...)

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 ....

WM9VCM in .MKV safe?

Reply #14
There is some weird stuff in your post:
Quote
so in the end it may be a single bit only, causing no damage at all to the decoder !!
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

 

WM9VCM in .MKV safe?

Reply #15
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 .....