by fphantom » Sat Jul 11, 2020 1:24 am
When converting from accurately ripped WAV to FLAC or WAV to ALAC M4A, the resultant track is not always a bit-perfect copy of the original. This is reproducible for particular tracks on particular CDs and in a quick test I found many but not all of my CD rips are affected. For those affected it is most often one faulty track per album but sometimes more.
A reproducible procedure to replicate is as follows:
1. Rip a CD to WAV files (one file per track) with Exact Audio Copy v1.3 and verify a perfect rip with both CTDB and AccurateRip
2. Convert WAV files to FLAC (or ALAC) in Media Monkey
3. Check accuracy with CUEtools, and (in this example) track #10 of 14 no longer accurate, all other 13 tracks accurate. Same track affected for FLAC or ALAC conversion.
To narrow down the cause of this data corruption bug:
4. Check original WAV files with CUEtools, all still accurate
5. Convert original WAV files to FLAC in CUETools and check: CUETools conversion is all accurate.
6. Convert accurate CUETools FLAC files to ALAC in Media Monkey, all still accurate
So the problem appears to be in the WAV reading portion of the Media Monkey conversion algorithm.
This reveals at least two serious problems with MediaMonkey:
1. There is consistent silent corruption of data on conversion of certain WAV files
2. MediaMonkey apparently does not verify the audio stream in files after it has written them. For lossless destination formats, MediaMonkey should verify the resultant converted file, especially if the format conversion is set to replace the original. Such verification should occur before any originals are removed, and if implemented properly this would have surely revealed the existence of the bug above before the faulty software was released.
I am using the latest MediaMonkey 4.1.28.1905 (Standard Edition) on Windows 10, 64bit, build 1903. But I can also see this data corruption problem has been in MediaMonkey since at least MediaMonkey 4.1.23, which I first used to convert my WAV files to FLAC, as some of my rips from that time are also affected.
When converting from accurately ripped WAV to FLAC or WAV to ALAC M4A, the resultant track is not always a bit-perfect copy of the original. This is reproducible for particular tracks on particular CDs and in a quick test I found many but not all of my CD rips are affected. For those affected it is most often one faulty track per album but sometimes more.
A reproducible procedure to replicate is as follows:
1. Rip a CD to WAV files (one file per track) with Exact Audio Copy v1.3 and verify a perfect rip with both CTDB and AccurateRip
2. Convert WAV files to FLAC (or ALAC) in Media Monkey
3. Check accuracy with CUEtools, and (in this example) track #10 of 14 no longer accurate, all other 13 tracks accurate. Same track affected for FLAC or ALAC conversion.
To narrow down the cause of this data corruption bug:
4. Check original WAV files with CUEtools, all still accurate
5. Convert original WAV files to FLAC in CUETools and check: CUETools conversion is all accurate.
6. Convert accurate CUETools FLAC files to ALAC in Media Monkey, all still accurate
So the problem appears to be in the WAV reading portion of the Media Monkey conversion algorithm.
This reveals at least two serious problems with MediaMonkey:
1. There is consistent silent corruption of data on conversion of certain WAV files
2. MediaMonkey apparently does not verify the audio stream in files after it has written them. For lossless destination formats, MediaMonkey should verify the resultant converted file, especially if the format conversion is set to replace the original. Such verification should occur before any originals are removed, and if implemented properly this would have surely revealed the existence of the bug above before the faulty software was released.
I am using the latest MediaMonkey 4.1.28.1905 (Standard Edition) on Windows 10, 64bit, build 1903. But I can also see this data corruption problem has been in MediaMonkey since at least MediaMonkey 4.1.23, which I first used to convert my WAV files to FLAC, as some of my rips from that time are also affected.
