EDIT3: fandango> I was completely ignorant about this interesting component I had to recover 260 GB of lossless music this summer due to HDD corruption ; I was able to test the recovered FLAC files with the VUplayer app but I'm still looking for a way to check the integrity of the WavPack files. I dreamt about such foobar2000 components. I will look for it. Thanks !!!
To me this suggests that the amount of recoverable data is dependent on the compression used.
guruboolez, how would your experiment with manually corrupting the files apply to normal conditions (without modifiying them intentionally) ? What conditions are mandatory to make an .ape file non-playable ? I've never seen anyone reporting such problems in real life. Any links ?Thank you
In real life if you get a bad hard drive you will loose more than a few bytes, what ever the sector size is
Well, the reasons for avoiding Monkey's audio regarding corruption due to losing some few bytes seem to me pretty vague
Also, WavPack currently has a CRC in each block for the decoded audio data, but I have been considering adding a CRC to cover the entire block.
This brings me to a caveat, and that is that there is a certain amount of luck to this procedure. It's kind of like poking someone with a stick; most of the time you'd get them in the leg or the arm, but if you were really lucky you would get them in the eye and cause real trouble. Guru sent me a file some time about ago...
The only way a test like this could be truly fair is to introduce hundreds of random errors and see what percentage cause various levels of damage. Obviously a decoder should be written in such a way that no..
Finally, in fairness to Matt, I believe that the Monkey's Audio format (and the decoder) were designed long before this hysteria with "error robustness" started. The WavPack format back then would not tolerate a single bit error, and would in fact sometimes play full volume white noise until the end of the track! This kind of back and forth competition and learning is why the lossless encoders are as good as they are today, and why we're not all still using Shorten...
Bullshit, isn't it?
I do appreciate your demonstration of one of MAC's shortcomings. Will you be doing any tests comparing apples to apples when it comes to data corruption? I mean you did prove a valid point, but I don't think it should serve as a basis for making truly comparative claims (not that I'm accusing you of making any such claims) regarding error tolerance.
My point, however, is that at comprable levels of compression MAC doesn't fail like your example shows.
Don't forget that there's no comparable level of compression between FLAC and Monkey's Audio, because the latter compresses better than flac even with -c1000.
I guess it gets back to how one weights features when choosing a lossless codec.