CUETools versions 1.9.5 through 2.1.4 (current), AccurateRip support & more Options

[IceFreak2000]

Whenever I try to rip a CD using CueRipper, I always get an error stating that there were 15 suspicious sectors, although the rip has been confirmed with Accurip; for an example, the CD I've just tried produced the following Accurip file:

CODE

[CUETools log; Date: 10/03/2012 11:30:36; Version: 2.1.2a]
[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found.
[ CTDBID ] Status
[215e14c2] (1/2) Differs in 710 samples @58:26:43-58:26:44
[9e9c6c34] (1/2) Accurately ripped
[AccurateRip ID: 001f4d67-016255cf-c70db20f] found.
Track [ CRC ] Status
01 [0729a137] (04/32) Accurately ripped
02 [6dc2ef07] (04/32) Accurately ripped
03 [942a1c47] (04/32) Accurately ripped
04 [3e9c91b6] (04/32) Accurately ripped
05 [00f5b2e0] (04/32) Accurately ripped
06 [8ec50bcd] (04/32) Accurately ripped
07 [228a631f] (04/32) Accurately ripped
08 [084ab80e] (04/32) Accurately ripped
09 [ba9a8ed6] (04/31) Accurately ripped
10 [b4faabe6] (04/32) Accurately ripped
11 [4c61993f] (04/32) Accurately ripped
12 [980f5e20] (04/32) Accurately ripped
13 [51070d0f] (04/31) Accurately ripped
14 [ce9d5a83] (04/31) Accurately ripped
15 [1f5281df] (04/29) Accurately ripped
Offsetted by 1879:
01 [1321ed77] (02/32) Accurately ripped
02 [2a4a5c4e] (02/32) Accurately ripped
03 [5a28826a] (02/32) Accurately ripped
04 [3f160e1d] (02/32) Accurately ripped
05 [592e74cf] (02/32) Accurately ripped
06 [388dbbda] (02/32) Accurately ripped
07 [124d08a5] (02/32) Accurately ripped
08 [4edeb39b] (02/32) Accurately ripped
09 [408366d0] (02/31) Accurately ripped
10 [8ebca252] (02/32) Accurately ripped
11 [06f884e7] (02/32) Accurately ripped
12 [cc92ee8c] (02/32) Accurately ripped
13 [0552cee7] (02/31) Accurately ripped
14 [13c98641] (02/31) Accurately ripped
15 [e1889663] (02/29) Accurately ripped
Offsetted by 2713:
01 [e03f2aff] (16/32) Accurately ripped
02 [40038405] (16/32) Accurately ripped
03 [3ecee28a] (16/32) Accurately ripped
04 [88447f34] (16/32) Accurately ripped
05 [0cfba08e] (16/32) Accurately ripped
06 [d058da0d] (16/32) Accurately ripped
07 [fd5ff960] (16/32) Accurately ripped
08 [63891968] (16/32) Accurately ripped
09 [721e03c5] (15/31) Accurately ripped
10 [b1f79bc8] (16/32) Accurately ripped
11 [ab29209d] (16/32) Accurately ripped
12 [cfbabb8f] (16/32) Accurately ripped
13 [c8cb2ec1] (15/31) Accurately ripped
14 [8e80b899] (15/31) Accurately ripped
15 [d0512438] (00/29) No match but offset

Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [0EDAF71A] [3E355924]
01 93.2 [88F41CD8] [D57DC7E0]
02 72.5 [C64A2F25] [A6B1C7EA]
03 95.4 [BBA16AB2] [3FD6FC02]
04 87.3 [236D2E8E] [103E0353]
05 80.7 [038E3D95] [1A09CAB9]
06 94.6 [DF0DF23F] [4DFC12DD]
07 84.2 [6A17FA2E] [BDC00B01]
08 99.9 [3A5BA7CD] [D07AC925]
09 90.9 [2E4D3AE1] [E8914DFB]
10 88.0 [9AC6C7C8] [BD3FF92A]
11 74.9 [023E329B] [4CBE857B]
12 87.1 [A3F378CF] [E5B9B1CC]
13 92.4 [DE103A96] [7A326BE4]
14 75.0 [52A4E116] [5B5BFA5A]
15 69.6 [2391AED3] [0C0A645C]

The CueRipper log shows:

CODE

CUERipper v2.1.2 Copyright © 2008-10 Gregory S. Chudov

EAC extraction logfile from 10. March 2012, 11:30

Motörhead / All the Aces: The Best of Motörhead

Used drive : HL-DT-ST DVDRAM GH20NS15 Adapter: 1 ID: 0

Read mode : Burst
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 667
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 2:48.30 | 0 | 12629
2 | 2:48.30 | 4:34.72 | 12630 | 33251
3 | 7:23.27 | 4:43.50 | 33252 | 54526
4 | 12:07.02 | 2:52.60 | 54527 | 67486
5 | 14:59.62 | 5:22.53 | 67487 | 91689
6 | 20:22.40 | 3:21.62 | 91690 | 106826
7 | 23:44.27 | 3:09.20 | 106827 | 121021
8 | 26:53.47 | 3:40.15 | 121022 | 137536
9 | 30:33.62 | 4:16.53 | 137537 | 156789
10 | 34:50.40 | 2:46.02 | 156790 | 169241
11 | 37:36.42 | 2:39.03 | 169242 | 181169
12 | 40:15.45 | 4:27.02 | 181170 | 201196
13 | 44:42.47 | 3:15.28 | 201197 | 215849
14 | 47:58.00 | 5:11.35 | 215850 | 239209
15 | 53:09.35 | 5:17.15 | 239210 | 262999


Range status and errors

Selected range

Filename D:\Rip\Motörhead\1993 - All the Aces_ The Best of Motörhead\Motörhead - All the Aces_ The Best of Motörhead.wav

Suspicious position 0:57:54

Peak level 99.9 %
Range quality 100.0 %
Test CRC 0EDAF71A
Copy CRC 0EDAF71A
Copy OK

There were errors


AccurateRip summary

Track 1 accurately ripped (confidence 4) [0729A137]
Track 2 accurately ripped (confidence 4) [6DC2EF07]
Track 3 accurately ripped (confidence 4) [942A1C47]
Track 4 accurately ripped (confidence 4) [3E9C91B6]
Track 5 accurately ripped (confidence 4) [00F5B2E0]
Track 6 accurately ripped (confidence 4) [8EC50BCD]
Track 7 accurately ripped (confidence 4) [228A631F]
Track 8 accurately ripped (confidence 4) [084AB80E]
Track 9 accurately ripped (confidence 4) [BA9A8ED6]
Track 10 accurately ripped (confidence 4) [B4FAABE6]
Track 11 accurately ripped (confidence 4) [4C61993F]
Track 12 accurately ripped (confidence 4) [980F5E20]
Track 13 accurately ripped (confidence 4) [51070D0F]
Track 14 accurately ripped (confidence 4) [CE9D5A83]
Track 15 accurately ripped (confidence 4) [1F5281DF]

All tracks accurately ripped

End of status report

Any ideas why CueRipper should be reporting an error? Is it something to do with my drive?

When ripping with EAC + CTDB, I get the following:

CODE

Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 10. March 2012, 12:02

Motörhead / All the Aces: The Best of Motörhead

Used drive : HL-DT-STDVDRAM GH20NS15 Adapter: 4 ID: 1

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes

Read offset correction : 667
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000

Used output format : User Defined Encoder
Selected bitrate : 896 kBit/s
Quality : High
Add ID3 tag : Yes
Command line compressor : C:\Program Files (x86)\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -6 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 2:48.30 | 0 | 12629
2 | 2:48.30 | 4:34.72 | 12630 | 33251
3 | 7:23.27 | 4:43.50 | 33252 | 54526
4 | 12:07.02 | 2:52.60 | 54527 | 67486
5 | 14:59.62 | 5:22.53 | 67487 | 91689
6 | 20:22.40 | 3:21.62 | 91690 | 106826
7 | 23:44.27 | 3:09.20 | 106827 | 121021
8 | 26:53.47 | 3:40.15 | 121022 | 137536
9 | 30:33.62 | 4:16.53 | 137537 | 156789
10 | 34:50.40 | 2:46.02 | 156790 | 169241
11 | 37:36.42 | 2:39.03 | 169242 | 181169
12 | 40:15.45 | 4:27.02 | 181170 | 201196
13 | 44:42.47 | 3:15.28 | 201197 | 215849
14 | 47:58.00 | 5:11.35 | 215850 | 239209
15 | 53:09.35 | 5:17.15 | 239210 | 262999


Range status and errors

Selected range

Filename D:\Rip\Motorhead - All The Aces\Motörhead - All the Aces- The Best of Motörhead.wav

Peak level 99.9 %
Extraction speed 28.2 X
Range quality 100.0 %
Copy CRC 0EDAF71A
Copy OK

No errors occurred


AccurateRip summary

Track 1 accurately ripped (confidence 4) [0729A137] (AR v1)
Track 2 accurately ripped (confidence 4) [6DC2EF07] (AR v1)
Track 3 accurately ripped (confidence 4) [942A1C47] (AR v1)
Track 4 accurately ripped (confidence 4) [3E9C91B6] (AR v1)
Track 5 accurately ripped (confidence 4) [00F5B2E0] (AR v1)
Track 6 accurately ripped (confidence 4) [8EC50BCD] (AR v1)
Track 7 accurately ripped (confidence 4) [228A631F] (AR v1)
Track 8 accurately ripped (confidence 4) [084AB80E] (AR v1)
Track 9 accurately ripped (confidence 4) [BA9A8ED6] (AR v1)
Track 10 accurately ripped (confidence 4) [B4FAABE6] (AR v1)
Track 11 accurately ripped (confidence 4) [4C61993F] (AR v1)
Track 12 accurately ripped (confidence 4) [980F5E20] (AR v1)
Track 13 accurately ripped (confidence 4) [51070D0F] (AR v1)
Track 14 accurately ripped (confidence 4) [CE9D5A83] (AR v1)
Track 15 accurately ripped (confidence 4) [1F5281DF] (AR v1)

All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found, Submit result: _uGvLH10IxqfR4ZETg_p5mkWEpw- has been confirmed
[215e14c2] (1/3) Differs in 710 samples @58:26:43-58:26:44
[9e9c6c34] (2/3) Accurately ripped
You can use CUETools to repair this rip.


==== Log checksum B86A826E81C4C480ECB0ED5FE371F678BA6921EE19A4E62D0D7B5754B5A01B10 ====

[Porcus]

Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?

[korth]

Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.

[IceFreak2000]

Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?

I'm using EAC 1.0 beta 3; that's the latest version right?

The '15 suspicious errors' report happens every time with CueRipper for *any* CD that I attempt with it.

Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.

No, I've tried Secure and Paranoid modes in CueRipper and apart from exponentially increasing the time taken to rip it always produces the same result

[lipidicman]

Are the errors always right at the end of the disc? They are for the log you posted.

This is why the rip passes accuraterip. It should also pass CTDB. I'm not sure what the CTDB issues are with this disc. Do you usually get a good CTDB result?

I think it is the drive, it seems to be like when a drive that cannot overread is asked to (although CueTools does not overread). This is a complete speculation though.

[korth]

This is why the rip passes accuraterip.

I know the logs are hard to read as posted. The (possible) error in the CUERipper log as posted occurred between 31 & 32 seconds from the end of the disc. Too far to pass accuraterip on an offset issue. I said possible error because the CRC32s are the same in both logs and the EAC log had no errors reported.

it seems to be like when a drive that cannot overread is asked to

It does (sort of) resemble the error that occurs when overread is incorrectly enabled in EAC.

[lipidicman]

Yes, I was looking at Differs in 710 samples @58:26:43-58:26:44, rather than Suspicious position 0:57:54

Odd.

[Dario]

Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.

This post has been edited by Dario: Mar 25 2012, 10:27

[krafty]

any chance of having this tool natively on linux

This post has been edited by krafty: Apr 5 2012, 16:51

[tuxman]

Depends. As it is written in C#, you'd need the Mono framework anyway.

[Gregory S. Chudo...]

Well, it's written in C# and i have no plans to rewrite it in any other language, so if you don't count mono as 'natively', then the answer is no. What i was considering to do, but haven't found the time, is to at least test it on linux before releasing each version, and maybe create a separate download where it's bundled with mono libs using mkbundle, but i'm not sure how will plugins work in this scenario.

[Gregory S. Chudo...]

I need help to decide on tag mapping in CUETools.
CTDB metadata contains at least three useful pieces of data that aren't currently written as tags. Those are Release Date, Label and Catalog#.
When using FLAC, i was planning on storing them as "RELEASEDATE", "LABEL" and "LABELNO".
According to http://sublevelseven.com/resources/1/, those should map to "TDRL", "labl" and "cat#" in mp4, and to "TDRL", "TPUB" and ?nothing in mp3.
But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.
Also no idea how to store release country and disc name .

[korth]

But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.

Isn't "ALBUM ARTIST" unique to foobar2k (and CUETools)?

I'd say "RELEASEDATE", "PUBLISHER", and "CATALOG" but don't see why foobar2k's "RELEASE DATE" or your choice of "LABEL" and "LABELNO" wouldn't work also.

Also no idea how to store release country and disc name.

You're getting into "User defined" or "TXXX" territory with "Release Country" and "Disc Name". I'd say "COUNTRY" or "RELEASECOUNTRY" and "DISCNAME"

But this is just my 2 cents. Additional discussion welcome.

[Kevin04]

Here are some facts regarding LABEL / PUBLISHER and foobar2000:
-For VorbisComment (FLAC), foobar2000 prefers PUBLISHER over ORGANIZATION (Label). It shows values from those fields only as PUBLISHER in the properties of a file.
-foobar2000 can not read multiple values in the TPUB (PUBLISHER) field in ID3v2.

So, if you want to base your tags on foobar2000, I'd go with PUBLISHER for VorbisComment. I don't know if you need multiple values for ID3v2, but if you do, I'd use a custom TXXX frame. If not, TPUB would work fine.

I would also use TYER (ID3v2.3) / TDRC (ID3v2.4) instead of TDRL for the release date. As far as I know, the usage of TYER/TDRC is vast compared to TDRL, which is very rarely used. DATE for VorbisComment.

As for the other tags, personally I'm using the custom tags CATALOG NUMBER (except CATALOG for APEv2 and CATALOG_NUMBER for Matroska, which are specified), DISCNAME and RELEASE LOCATION.

This post has been edited by Kevin04: Apr 13 2012, 19:41

[Gregory S. Chudo...]

Thank you. One clarification: i mentioned TDRL, because i want to store release date, as opposed to recording date or original release date, which is usually stored as TYER/TDRC. For example, the latest remaster of Pink Floyd's DSotM would have TDRC=1973 and TDRL=2011. Although according to spec, TDRL is also supposed to store original release date

This post has been edited by Gregory S. Chudov: Apr 13 2012, 20:10

[Kevin04]

Yes, I know. I wanted to use TDRL at first too, but everyone's using TYER/TDRC for release date (even though it's actually recording date), so for compatibility, I went with it, too. It's kind of a mess.

[Gregory S. Chudo...]

Both discogs & muscibrainz return two dates, and i already use TYER for recording/original release date, so i have to use something different for actual release date in case of remastered albums. If i were to use TYER for actual release date, this would only lead to question where to store original release date... TORY isn't well used either. What's more importantly, all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release. And for those who still want to keep track of remasters, TDRL will probably have to do.

Some news about release country: TagLib has MusicBrainzReleaseCountry field, which used "RELEASECOUNTRY" for VorbisComment and APEv2, and TXXX MusicBrainz Album Release Country for mpeg... They seem to use http://wiki.musicbrainz.org/PicardQt/TagMapping

This document also recommends DISCSUBTITLE/TSST for disc name.

This post has been edited by Gregory S. Chudov: Apr 14 2012, 03:59

[mjb2006]

Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release.

Not that I have access to very many people's collections to verify, but from what I've seen, it's quite rare to have more than one date in tags: the one date provided is nearly always the actual release date (year alone, usually), as that's all that the metadata sources tend to provide. The situation is the same in the digital releases I've purchased.

I do prefer my TYER to be the original release date, so I make that change and then put the remaster/compilation date in prose in COMM because I don't know what else to do (in foobar2000). I think most people don't even bother; if the music is from 1977 but the reissue/remaster/compilation came out in 2008, probably the TYER is already set to 2008, and they just leave it as-is.

[Gregory S. Chudo...]

Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.
I'm talking about musicbrainz/discogs data as returned by CTDB, which provides both dates.

I do prefer my TYER to be the original release date

Exactly. So i think CUETools should do the same, and store remaster date in TDRL.
We all know that the world of tag mapping is in a complete mess, but something has to be done, we can't just give up
In the last few days i've read about a dozen different tag mapping documents from various software vendors, and it's given me a headache.
They cannot agree on anything. So i guess i'll just have to use my own judgement in each case and at least try not to create new names for the same entities.

[mjb2006]

Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.

Sort-of, but not exactly. The year reported in the Discogs master release is just the earliest year from among the actual release dates of the releases in the set. For albums and singles, this can be safely interpreted as the original release date, and usually it works for the songs on the release. But this interpretation fails for most compilations, or any other album on which there are songs culled from prior years. On those types of releases, a given song's original release date is almost never the same as the release date of any edition of the compilation. So if you're tagging individual tracks, there's no easy way to use Discogs data to get actual original release dates for each song, at least not without some creative use of the search engine.

I don't recall what MusicBrainz does, but I think it's the same kind of situation.

[Gregory S. Chudo...]

In musicbrainz you can actually find the first release date of a given recording, even if it was released in different release groups.
Each track of each release has a link to a recording, for example here is 'The End' by 'The Doors': http://musicbrainz.org/recording/1423fcd8-...75-082af4ba45c1
You can easily see that the original release date for this recording is 1967-01-04, and you can get to this data from any compilation release.
But CTDB currently doesn't return this data, i'm not sure how relevant it is.

Anyways, this would probably be a third tag For example, a track originally released in in 1967, included in 2001 remaster of 1995 compilation could have TDOR=1967, TYER=1995, TDRL=2001.
Putting individual track release years in TYER could lead to strange behavior in many applications, because the tracks from this compilation could end up in different folders, or in different groups in the playlist.

[Dario]

Gregory, do you have a possible explanation of this:

Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.

[Gregory S. Chudo...]

Sorry, i haven't got around to this yet.

UPD: tried to reproduce it, but couldn't. In theory this can only happen if takc.exe crashes on startup.
foobar2000 uses foo_input_tak.dll instead of takc.exe, so it's not affected.
I wanted to switch to TAK SDK in CUETools, but it only provides 32-bit dll.
And frankly, i don't want to waste any time on a codec for which there's no open-source decoder.

This post has been edited by Gregory S. Chudov: Apr 17 2012, 02:11

[Gregory S. Chudo...]

CUETools 2.1.4 is out, http://www.cuetools.net/install/CUETools_2.1.4.rar
If no serious bugs will be found in the next few days, this will be declared the new stable version.

[marc2003]

there seems to be a bug in the multi select browser when pressing f5 to refresh. although the "local db" node is present, it cannot be expanded to view anything and it takes a restart to work again.

edit: using + and * keyboard shortcuts around my numpad works but i'm pretty sure it could be done with the mouse before.

This post has been edited by marc2003: Apr 17 2012, 06:13