All rips failing AccurateRip (regression wrt. MM3) [#9199]

[simonbrads]

I have FLAC CD rips that I've verified against AccurateRip using CUETools. I recently, for unimportant reasons, re-ripped some of my CDs -- and now they fail AR verification in CUETools.

I've done some analysis (using "flac -d" and my own WAV decoder), and the data chunk of ALL of my MM4-1476 rips have extra bytes prepended and/or appended, compared with the proven-correct rips generated by MM3 a year or so ago. I've also verified this behaviour using the same drive as previously, as well as with a new BR-RW drive (both LG, offset 667).

The pattern is always the same: the first track is longer by 14,112 bytes; the last track is longer by 11,760 bytes; and all the in-between tracks are longer by 25,872. As you may guess, if you're any good at mental arithmetic, every track that's followed by another (i.e., every one but the last) has an additional 14,112 bytes appended to the end; and every track that's preceded by another (i.e., every one but the first) has an additional 11,760 bytes prepended to the beginning.

What on earth are these extra bytes? While it's possible this isn't actually a bug, it seems a bit odd that it causes the generated files to fail AR verification. (The error is "CD not in database, by the way, because the track lengths are wrong. If I manually remove the extra bytes and fix the chunk lengths accordingly, AR verification passes (as the WAVs are then identical to the MM3-generated ones checked earlier).)

Appreciate any insight from those more knowledgeable than myself.

Cheers,
Simon

[simonbrads]

I should post an example. This one's Macy Gray's "On How Life Is", MM3 WAVs (from FLAC):

mm3\wav\01 Why Didn't You Call Me.wav: AR: offset 39, rip accurate (210/401), CTDB: verified OK, confidence 335.
.
.
.
mm3\wav\10 The Letter.wav: recently verified: AR: offset 39, rip accurate (210/401), CTDB: verified OK, confidence 335.

and MM4:

mm4\wav\01 Why Didn't You Call Me.wav: AR: disk not present in database, CTDB: disk not present in database.
.
.
.
mm4\wav\10 The Letter.wav: AR: disk not present in database, CTDB: disk not present in database.

And this is what my WAV decoder had to say about track 1, MM3:

ckID = RIFF
cksize = 33885300
waveID = WAVE

ckID = fmt
cksize = 16
wFormat = 1
nChannels = 2
nSamplesPerSec = 44100
nAvgBytesPerSec = 176400
nBlockAlign = 4
wBitsPerSample = 16

ckID = data
cksize = 33885264
data = 9F-A4-21-70-BC-54-11-C5-81-28-F5-70-33-D9-7F-39-90-DA-10-62

and MM4:

ckID = RIFF
cksize = 33899412
waveID = WAVE

ckID = fmt
cksize = 16
wFormat = 1
nChannels = 2
nSamplesPerSec = 44100
nAvgBytesPerSec = 176400
nBlockAlign = 4
wBitsPerSample = 16

ckID = data
cksize = 33899376
data = 1D-AF-48-04-C9-7C-CD-40-A5-FD-2B-8F-13-D6-85-C8-A6-11-BD-7A

("data" is a SHA1 hash, so just useful to see whether or not they're equal.)

[simonbrads]

I've done a little more analysis this morning, and this doesn't seem good! Looking at the metadata in the FLAC (different album this time), MM3:

METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 6011 bytes
maximum framesize: 13108 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 38075940
MD5 signature: b531214b659e13789f9c5f737b3317fb

and MM4:

METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 4885 bytes
maximum framesize: 13028 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 38082408
MD5 signature: 3f6db56b1ce68c7e6ea59cdee2a54dd0

38082408 - 38075940 = 6,468 samples (= 25,872 / (2 * 2))
6,468 / 44.100 = 146.7 milliseconds

Now look at this screenshot I've just taken from a very zoomed-in Audacity. It shows two consecutive tracks (Tunnel of Love and Telegraph Road from Alchemy: Dire Straits Live). (Image is clipped in my browser; open in a new tab, if you want to see all the way to the right.)



Notice the identical sections: the tracks are overlapping by 146.7 ms. (Inferring from the "known good" MM3 rips, 80.0 ms of this is appended to the end of the first track, and 66.7 ms is prepended to the beginning of the second.)

Unless there's something fundamental I'm missing here, this cannot be right!?

Thanks,
Simon

[simonbrads]

This is caused by MM's own AccurateRip verification option. Turn this off, and the generated FLAC files are correct; turn it on, and you get the extra bytes on every track.

I've just reproduced this on my laptop, so it's not just my PC.

[MiPi]

Thanks, you're right, I have reproduced it here. Tracked as http://www.ventismedia.com/mantis/view.php?id=9199

[simonbrads]

Thanks for the confirmation!

I'm not sure I'd consider it a minor bug, though. For me, it should be critical, or at least major (as there's a workaround: don't use the verify option): the generated WAV/FLAC files (and possibly other formats) are basically corrupted. And this is a worst-case scenario, because MM is explicitly saying that the files are correct. Also, the sort of people who would use the verify option are those who are most interested in getting bit-perfect rips -- but, ironically, they're exactly the people who won't! (And I doubt they'll be happy when they realize. )

Cheers,
Simon

[cnapan]

I just spent an afternoon evaluating Mediamonkey and decided to pay for the gold version, only to discover that I can't rip anything with the verify rip checkbox ticked, and I guess this thread explains why.

Hope this gets fixed soon. I probably wouldn't have bought if I'd known this feature wouldn't work!

[Lowlander]

It is fixed in 4.0.5.1481 available as beta: http://www.mediamonkey.com/forum/viewto ... 80#p335880

[marcsansoucie]

Is it likely that this would cause audible artifacts (clicks, brief repeats, etc) during transitions from one track to another? I've noticed those artifacts with CDs I've recently ripped with MM4 4.0.3.1476. Once I noticed this bug report, I re-ripped a couple CDs with Exact Audio Copy and have not heard the same artifacts. I'm guessing I need to re-rip any CD I've ripped with MM4, which is not a delightful prospect, but if this bug fix truly eliminates the problem, I'll be OK. Thanks for any information.

Marc

[MiPi]

Is it likely that this would cause audible artifacts (clicks, brief repeats, etc) during transitions from one track to another? I've noticed those artifacts with CDs I've recently ripped with MM4 4.0.3.1476. Once I noticed this bug report, I re-ripped a couple CDs with Exact Audio Copy and have not heard the same artifacts. I'm guessing I need to re-rip any CD I've ripped with MM4, which is not a delightful prospect, but if this bug fix truly eliminates the problem, I'll be OK. Thanks for any information.

Marc

Yes, this bug could cause audible artefacts at the very end of ripped songs. Because it means, that there are some buggy data in the audio data part of the file, the only solution is to re-rip affected files or edit them using some audio file editor and remove clicks manually.