AccurateRip Pre-emphasis Bug?

[Z-Lemur]

Hi Spoon, I believe there is a bug in AccurateRip for discs ripped with varying pre-emphasis.

After the last update, my CD with a mix of tracks with and without pre-emphasis ripped perfectly. However, when having AccurateRip scan my collection, this is what comes up:



The tracks marked as having errors all had pre-emphasis decoded. Ripping log shows the tracks ripped accurately.

Hope this helps.
Z-Lemur

[Spoon]

R2025-11-12

Fixed the issue of pre-emphasis being incorrectly applied for mixed pre-emph discs.

[simbun]

The tracks marked as having errors all had pre-emphasis decoded. Ripping log shows the tracks ripped accurately.

Surely the decoded tracks won't verify will they, given they're now different to the CD?

This is one of the reasons I keep a copy of the original PRE/HDCD disc rips

[Spoon]

AccurateRip happens before pre-emphasis, so it would not effect verification.

[simbun]

AccurateRip happens before pre-emphasis, so it would not effect verification.

Z-Lemur is verifying post-rip with PerfectTunes.

[Spoon]

Then it would

[simbun]

Then it would

fail to verify?

Unless you're assuming that the following options are set:

• CD Ripper: CD Ripper Options > Meta Data & ID Tag > Options > Write ID Tags: AccurateRip Result
• PerfectTunes: Use AccurateRipResult from ID Tag

In other words, the audio isn't checked just the tags.

[Z-Lemur]

Hi All,

I ripped the disc above with R2025-11-12 and the log says that both the pre-emphasis and non-pre-emphasis tracks ripped accurately. Checking my collection in PerfectTunes, it shows the decoded tracks as having errors.

I'm curious because I have Pink Floyd's "The Wall" album with pre-emphasis. Decoding that entire album does not show as having errors in PerfectTunes.

Z-Lemur

[Spoon]

Pre-emphasis changes the audio, it will never match to AccurateRip if it has been applied.

It is likely the Wall is not have pre-emphasis applied (if the check is to check actual audio data, rather than the stored tag value).

[simbun]

if the check is to check actual audio data, rather than the stored tag value

With regards to relying on the tags, it wouldn't be so bad if PerfectTunes at least performed a decode test, but as it is I can corrupt a FLAC file and the AccurateRip checks still pass.

$ flac -t 01.01.flac

flac 1.4.3
Copyright (C) 2000-2009  Josh Coalson, 2011-2023  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

01.01.flac: ok


$ printf "x01" | dd of="01.01.flac" bs=1 seek=10408448 count=1 conv=notrunc

$ flac -t 01.01.flac

flac 1.4.3
Copyright (C) 2000-2009  Josh Coalson, 2011-2023  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

01.01.flac: *** Got error code 2:FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
*** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC


01.01.flac: ERROR while decoding data
            state = FLAC__STREAM_DECODER_ABORTED

Using the tags is in my opinion a bad default.

[Spoon]

PerfectTUNES has a check on that, part of the scanning process it will highlight corrupted tracks. Clear the database and it will rescan the files.