Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Von]

I hooked up my external DVD burner to another computer today than the laptop I normally use for ripping. I decided to do a test rip, and see if it matched the previous rip on my laptop. The results were different files, I guess because of different offset.

I found this a bit surprising, because I expected the offset to be the same, and the ripped files to be identical. I did a new rip on my laptop, and this matched today's rip on the new computer. It turned out that the old rip on my laptop was done using MC 16.0.181. Both tests today were done with MC 17.0.99.

So, my questions are:

1. Does the offset vary with different versions of MC?
2. If it does, wouldn't it be better to avoid this if possible?
3. Will a given drive give identical results regardless of which computer is being used?

[Von]

Just to make sure this wasn't caused by a driver update, I used EAC to re-rip a CD previously ripped with EAC. The files matched, so it seems that this is caused by a change in MC.

[Alex B]

The drives' physical read offsets may vary slightly from a drive model to another. This has no audible effect because you can't really hear such small differences, but naturally if the read offsets are different also the resulting PCM contents differ. If you get identical files from two different drives when you use MC17 for ripping, then these two drive models happen to have the same read offset.

MC doesn't adjust the offset anyhow and the rippers in MC16 and MC17 should produce identical audio content when the same drive is used and no read errors occur.

However, the header and tag data inside the files may be different even when the audio contents do not differ. At least one file tag is automatically different, the MC version number. Even if the file format is WAV, the difference may be caused by tagging because in MC17 WAV tagging is enabled by default. In MC16 WAV tagging must be enabled by hand.

To reliably compare two audio files you must use a program that can compare the actual PCM audio content.

[Von]

I probably wasn't precise enough in my first post: All rips were done with the same drive.

I have now checked the files with EAC's comparison tool, and it turns out the audio contents of the files were indeed identical. This is a first for me! You must be right that this has to do with tagging of wav files in MC 17, which has not been done in previous versions.

Doh... I don't know why this has been implemented. Can I turn it off and make it work like before?

A part of my work flow has always been to rip first to wav, create an md5 checksum file for the wav files, then convert to lossless. It has been very useful to me, and I don't know any other way to verify later that a file is what I think it is. There is always the danger of accidentally converting via some lossy format, and still believing the file to be lossless.

The checksum test has always been very handy. I can convert a file to wav, check it against my original checksum, and know that it is indeed identical to the wav file I ripped. Do any of you have any other method that you can recommend?

 

[Alex B]

WAV tagging was introduced in MC14, but until now it has been disabled by default. You can still disable it: http://wiki.jriver.com/index.php/WAV_%26_AIFF_Tagging

I convert files files between lossless formats all the time. Before I delete the old files I always run the foobar2000 bit compare tool. (http://www.foobar2000.org/components/view/foo_bitcompare). You will need to install foobar2000 and at least the compare tool. Some file formats, like APE, need also a separate decoder plugin, but for example FLAC and WAV are supported by default. You can simply drag and drop all files that you want to compare to a foobar2000 playlist (first one set and then the other set in the same track order), select the files, and run the tool from the right-click > Utilities menu. The tool compares only the audio contents and in my experience it is very reliable.

[Von]

Thanks for the tips. It seems like a good way of doing things.

I still think that it would be nice if we didn't have to rely on other software to do something like this. In the old Monkey's Audio GUI there was a possibility to verify the integrity of ape files. (Perhaps there still is?) I suppose there is a checksum for the PCM data stored as metadata in the ape file? Perhaps this checksum could be saved as a separate file if one wanted to, and used to check against the pcm content of any audio file in MC?

I have always liked being able to save a checksum file as a reference after ripping. Anyway, if I am alone in missing an option like this, I guess I will have to find a workaround. Or change my workflow.