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

[Corwin]

Just wanted to let people know that the "CUE Tools has encountered a problem and needs to close." messages can be caused by running it over a (in my case Samba) network share. Copy it to the C drive to run it and it will work.

[Corwin]

Accurite rip reports the offset is wrong. I found out the correct offset is 30 so I put that in cueTOOLs and this is what I get:

[Disc ID: 000da5b7-00503621-540c9507]
Offset applied: 30
Track [ CRC ] Status
01 [2f18d0b0] (00/21) No matches
02 [a5c42498] (00/20) No matches
03 [d6c392c0] (00/21) No matches
04 [be3c27f3] (00/20) No matches
05 [441afd21] (00/20) No matches
06 [3cf8b0f2] (00/20) No matches
07 [4d636851] (00/20) No matches
Offsetted by 0:
01 [723f191a] (02/21) Accurately ripped as in pressing(s) #2
02 [01371491] (02/20) Accurately ripped as in pressing(s) #2
03 [dc2422c5] (02/21) Accurately ripped as in pressing(s) #2
04 [7b653671] (02/20) Accurately ripped as in pressing(s) #2
05 [7f3c7239] (02/20) Accurately ripped as in pressing(s) #2
06 [58b39608] (02/20) Accurately ripped as in pressing(s) #2
07 [ca758367] (02/20) Accurately ripped as in pressing(s) #2

I'm not sure I get the logic. However I can set the offset to 0 and get the report in 1.9.2, and then put the offset into 1.9.1 and apply it there.

This post has been edited by Corwin: Oct 19 2008, 10:50

[Corwin]

I thought this was pretty cool, it runs fine with Mono 2.0 in Ubuntu when compiled with only WAV support:

Too bad Mono doesn't support C++/CLI. There was some work on an extension for GCC to allow this but it looks like it's been abandoned. I wonder if P/Invoking into libFLAC (for example) would work...

Wow, how would I get a copy with only wav support? I'm already converting to FLAC in a bash script as I'm not interested in encoding in a VM and Windows is way too time consuming to keep all the codecs up to date anyway. A CLI version would be the ultimate... I've slowly been working on something similar as far as calculating the correct offset.. I got as far as correctly calculating the Diskids and submitting the request and receiving the track checksums. I have no clue how you're detecting the different pressings, AccurateRip only gives back the track checksum and confidence score.

[Caleb]

Hi Gregory,

Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.

Now I want to split the FLAC but CueTools doesn't like it

Try the updated version.

I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!

The CUE looks like this:

CODE

REM GENRE Rock
REM DATE 1982
REM COMMENT YEAR: 2001 ID3G: 17
PERFORMER "ДДТ"
TITLE "Свинья на радуге"
FILE "ДДТ - Свинья на радуге ( Переиздание XXI век, включая ранее неизданное ).flac" WAVE
  TRACK 01 AUDIO
    TITLE "Счастливый день"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "За 50 копеек"
    INDEX 00 04:07:04
    INDEX 01 04:07:09
  TRACK 03 AUDIO
    TITLE "Безжизненый край"
    INDEX 00 06:28:06
    INDEX 01 06:30:04
  TRACK 04 AUDIO
    TITLE "Ночь"
    INDEX 00 09:56:29
    INDEX 01 09:58:34
  TRACK 05 AUDIO
    TITLE "История"
    INDEX 00 18:05:22
    INDEX 01 18:07:10
  TRACK 06 AUDIO
    TITLE "Блюз"
    INDEX 00 20:20:35
    INDEX 01 20:22:03
  TRACK 07 AUDIO
    TITLE "Свинья на радуге"
    INDEX 00 25:34:22
    INDEX 01 25:36:34
  TRACK 08 AUDIO
    TITLE "Рыба"
    INDEX 00 28:07:52
    INDEX 01 28:10:23
  TRACK 09 AUDIO
    TITLE "Бродяга"
    INDEX 00 31:14:62
    INDEX 01 31:17:45
  TRACK 10 AUDIO
    TITLE "Дождь"
    INDEX 00 36:35:73
    INDEX 01 36:38:08
  TRACK 11 AUDIO
    TITLE "Не стреляй"
    INDEX 00 39:47:09
    INDEX 01 39:48:73
  TRACK 12 AUDIO
    TITLE "Игра"
    INDEX 00 43:30:45
    INDEX 01 43:32:57
  TRACK 13 AUDIO
    TITLE "Инопланетянин"
    INDEX 00 47:17:11
    INDEX 01 47:18:62
  TRACK 14 AUDIO
    TITLE "Вечер"
    INDEX 00 48:39:48
    INDEX 01 48:42:27
  TRACK 15 AUDIO
    TITLE "Все идет своим чередом"
    INDEX 00 50:42:33
    INDEX 01 50:44:47
  TRACK 16 AUDIO
    TITLE "Давайте что-нибудь придумаем"
    INDEX 00 54:35:37
    INDEX 01 54:39:63

This post has been edited by Caleb: Oct 19 2008, 12:30

[Gregory S. Chudo...]

Accurite rip reports the offset is wrong. I found out the correct offset is 30 so I put that in cueTOOLs and this is what I get:

[Disc ID: 000da5b7-00503621-540c9507]
Offset applied: 30
Track [ CRC ] Status
01 [2f18d0b0] (00/21) No matches
02 [a5c42498] (00/20) No matches
03 [d6c392c0] (00/21) No matches
04 [be3c27f3] (00/20) No matches
05 [441afd21] (00/20) No matches
06 [3cf8b0f2] (00/20) No matches
07 [4d636851] (00/20) No matches
Offsetted by 0:
01 [723f191a] (02/21) Accurately ripped as in pressing(s) #2
02 [01371491] (02/20) Accurately ripped as in pressing(s) #2
03 [dc2422c5] (02/21) Accurately ripped as in pressing(s) #2
04 [7b653671] (02/20) Accurately ripped as in pressing(s) #2
05 [7f3c7239] (02/20) Accurately ripped as in pressing(s) #2
06 [58b39608] (02/20) Accurately ripped as in pressing(s) #2
07 [ca758367] (02/20) Accurately ripped as in pressing(s) #2

I'm not sure I get the logic. However I can set the offset to 0 and get the report in 1.9.2, and then put the offset into 1.9.1 and apply it there.

I didn't quite get what you do to get such a log.
You run 1.9.2 in verify mode, and it tells you that your rip would be accurate offsetted by 30, right?
Then you do what? Put it in advanced settings->Write offset box and convert it to fix the offset?
And then you run verify again on the converted version?
Then you are doing wrong.

First, because you should have removed that write offset from advanced settings before verifying the converted version. Because it applies that offset again when verifying, so it tells you that 30 is a wrong offset, and it should be zero.

Second, because it all could have been done automaticly. You could turn on the 'Fix offset if' option in advanced settings, leaving 'write offset' option zero, and run CUETools in "Verify, then encode" mode. It would calculate the correct offset and immediately apply it upon conversion, you won't have to enter it manualy.

This post has been edited by Gregory S. Chudov: Oct 19 2008, 13:54

[Gregory S. Chudo...]

I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!

Okay, i see where it went wrong. There's is a safety measure - filenames are encoded so that they would be accessible from non-unicode applications (e.g. FAR manager). My default locale is russian, so it worked for me just fine I tested it on some swedish music that i have, and it worked fine too - substituting all those 'å' characters with 'a', etc. But there is no such substitution for cyrillic characters. So i guess i'll have to add another setting, to make this safety measure optional. The option would probably be called 'Make filenames ANSI-safe'. You would have to disable it in order to allow russian filenames in non-russian locale. For most users that option would be better left on.

Oh, and you will also have to disable "Remove special characters except" option.

This post has been edited by Gregory S. Chudov: Oct 19 2008, 14:29

[NachoMan77]

Gregory,

I can confirm that Update7 is now working with my APEs.

Got another request for you...

Can you make CUETools write an .accurip log even when the disc isn't found on the AR DB ?. This really helps when dealing with large batch transcoding.

Thanks.

N.

[fredhammersmith]

I have a question: can CueTools process hi-rez files, like 24/96?

[mhudson7]

I love this tool! Thanks to everybody for their time and efforts.

I can't wait for a rainy day!

[Moitah]

@Corwin: I will see about posting a WAV-only build later after I do some testing.

@fredhammersmith: No, it can't.

@Gregory: I just checked in some stuff, to support WAV-only compilation, and to fix some cosmetic issues -- control spacing, tab order, work around auto-scaling issue (e.g. users w/ 120 DPI display setting). Feel free to change anything back if it messes you up .

This post has been edited by Moitah: Oct 19 2008, 19:12

[Gregory S. Chudo...]

AccurateRipDiscID=018-0034a011-02b34812-18120f12-15
AccurateRipResult=AccurateRip: Accurate (confidence 10) [BFD8DBAE]
(track 15 of 18).

That's wierd.
So dbpoweramp puts the track number and total number of tracks in this tag.
I was thinking it's not neccecary, because the total number of tracks is stored in this ID anyway - in the last byte of cddb-id part. But in this case the cddb-id part shows there were 12 tracks: 018-0034a011-02b34812-18120f12-15
And dbpoweramp says there's 18. What could this mean? Is this a two-disc release, with 6 tracks on disc 1 and 12 tracks on disc two?

This post has been edited by Gregory S. Chudov: Oct 20 2008, 06:43

[Corwin]

Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.

I do one of the following to convert Russian to Unicode (UTF-8)

Non ASCII file:
enca -L russian -c -x UTF-8 filename

extended ASCII:
iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile > newfile


Works good on Linux, you can probably find the same utilities compiled on Windows (or do the intelligent thing and run Linux). I believe Windows uses UTF-16 for unicode, not UTF-8

good luck

Then you are doing wrong.

You're exactly right. Thanks for your help. It's working good now, no more OE (operator error).

[Porcus]

So dbpoweramp puts the track number and total number of tracks in this tag.
I was thinking it's not neccecary, because the total number of tracks is stored in this ID anyway - in the last byte of cddb-id part. But in this case the cddb-id part shows there were 12 tracks: 018-0034a011-02b34812-18120f12-15
And dbpoweramp says there's 18. What could this mean? Is this a two-disc release, with 6 tracks on disc 1 and 12 tracks on disc two?

First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

As for the "not necessary" part, the CDDB-ID trackcount and the AccurateRipDiscID trackcount might differ if there is a data track. According to Spoon, CDs might have the data track at the beginning (what he refers to as "Playstation" type) or at the end (I think this is common with the CDEnhanced type) -- I do not know whether there are CDs with a data sessions in both ends. At least the "Playstation" type return quite inconsistent tracknumberings from metadata sources, and evidently, some ripping/tagging applications will insist on the music starting at track #1, others will insist it starts at track #2.

(Maybe they will also differ if there is a "Hidden Track One Audio", i.e. a Track 1 Index 0 of more than two seconds, I might check when I get home; Track 0 is treated as an exception in AccurateRip because a few drives cannot extract the information and would insist on returning zeroes, so am I told.)

This post has been edited by Porcus: Oct 20 2008, 10:39

[Gregory S. Chudo...]

First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

Thanks a lot. I'm a complete idiot or i should sleep more often ^^

[Porcus]

First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

Thanks a lot. I'm a complete idiot or i should sleep more often ^^

And either way you have no time to fix it the next couple of years?

[Gregory S. Chudo...]

I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!

Check out the next update
Uncheck 'Remove special characters' and 'Force ANSI filenames'.

[NightOwl]

Moitah and Gregory, thank you so much for CUE Tools. I have been using it quite a lot for just over two weeks and I really like this tool. I especially love the AccurateRip database support that Gregory added.

[NightOwl]

I started using the latest Update 8 (after replacing Update 2). Now when I "Verify, don't encode", all of my FLAC files have their timestamps updated to the current time. In Update 2 this did not happen -- my FLAC files kept their original dates and times.

If I only verify my FLAC files, why do the dates and times of all those files need to be updated? I strongly prefer the previous behaviour.

[Gregory S. Chudo...]

I started using the latest Update 8 (after replacing Update 2). Now when I "Verify, don't encode", all of my FLAC files have their timestamps updated to the current time. In Update 2 this did not happen -- my FLAC files kept their original dates and times.

If I only verify my FLAC files, why do the dates and times of all those files need to be updated? I strongly prefer the previous behaviour.

That's because it writes AR tags.
For now you can turn off 'write tags' option (advanced settings->accurate rip).
I'll probably split it into 'write tags on encode' and 'write tags on verify'.
Or will preserving the file modification time be enough?

This post has been edited by Gregory S. Chudov: Oct 23 2008, 08:14

[NightOwl]

OK, thanks for the explanation, Gregory. The tooltip help for the AccurateRip "Write tags" feature says 'When using "apply offset" AccurateRip mode, also add ACCURATERIPCOUNT tag to flac files'. Since I wasn't applying any offset (only verifying), I didn't expect my FLAC files to be modified.

Preserving the file modification time would be more than enough for me (I would be very happy ). Your ideas of 'write tags on encode' and 'write tags on verify' sound good.

Perhaps you could add an option such as Mp3tag's "Preserve file modification time when saving tags" (which I always use)?

[Moitah]

IMHO even if the modified times are preserved, writing of tags during verification should be optional and disabled by default.

[NachoMan77]

IMHO even if the modified times are preserved, writing of tags during verification should be optional and disabled by default.

I totally agree with Moitah.

Gragory, Update 8 is looking good. I'm gonna test it a little further before I post my observations.

Nitpick: When Pause button is engaged, it should change the label to Resume, don't you think ?

N.

[NachoMan77]

Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

Here's the AR log for this file.

CODE

[Disc ID: 002df116-02674f90-03113b12]
Track    [ CRC    ] Status
01    [a9f3e40d] (00/04) No matches
02    [5eae1bf4] (00/04) No matches
03    [650b5c3a] (00/04) No matches
04    [48267af0] (00/04) No matches
05    [0fc1bae8] (00/04) No matches
06    [3cda61e7] (00/04) No matches
07    [d1891d55] (00/04) No matches
08    [1b80f43f] (00/04) No matches
09    [109806eb] (00/04) No matches
10    [fd02391a] (00/04) No matches
11    [a28b572b] (00/04) No matches
12    [643e9727] (00/04) No matches
13    [2ebfc088] (00/04) No matches
14    [a2f4fb66] (00/04) No matches
15    [0aee6e38] (00/04) No matches
16    [7b83e15e] (00/04) No matches
17    [cb9d7f5f] (00/04) No matches
18    [12b39bbc] (00/04) No matches
Offsetted by 2:
01    [04269899] (04/04) Accurately ripped as in pressing(s) #1
02    [e5fa7b7b] (04/04) Accurately ripped as in pressing(s) #1
03    [1b1f6861] (04/04) Accurately ripped as in pressing(s) #1
04    [e21a4d20] (04/04) Accurately ripped as in pressing(s) #1
05    [d93d5ea8] (04/04) Accurately ripped as in pressing(s) #1
06    [2c5ab0dd] (04/04) Accurately ripped as in pressing(s) #1
07    [3f05b528] (04/04) Accurately ripped as in pressing(s) #1
08    [3c602a68] (04/04) Accurately ripped as in pressing(s) #1
09    [77e0d0cf] (04/04) Accurately ripped as in pressing(s) #1
10    [9235c9b4] (04/04) Accurately ripped as in pressing(s) #1
11    [9357b2f7] (04/04) Accurately ripped as in pressing(s) #1
12    [9ddee790] (04/04) Accurately ripped as in pressing(s) #1
13    [ae9afba9] (04/04) Accurately ripped as in pressing(s) #1
14    [4a8f4038] (04/04) Accurately ripped as in pressing(s) #1
15    [a561c27e] (04/04) Accurately ripped as in pressing(s) #1
16    [e6453dde] (04/04) Accurately ripped as in pressing(s) #1
17    [d8b5ab66] (04/04) Accurately ripped as in pressing(s) #1
18    [a1c7a011] (04/04) Accurately ripped as in pressing(s) #1

thanks in advance,

N.

[Gregory S. Chudo...]

Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

thanks in advance,

N.

Well, it's functioning as designed. It was made for those users, who don't want to fix offsets.
Also you could use it in conjunction with 'fix offset if' option to automaticly fix offsets.
If you insist on manual offset correction, well, i can add another option to that 'convert only if' block: 'convert only if 100% tracks match with condidence >= 1 and zero offset'.
I'm only worrying that soon that options window will be so huge it won't fit on screen

[NachoMan77]

Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

thanks in advance,

N.

Well, it's functioning as designed. It was made for those users, who don't want to fix offsets.
Also you could use it in conjunction with 'fix offset if' option to automaticly fix offsets.
If you insist on manual offset correction, well, i can add another option to that 'convert only if' block: 'convert only if 100% tracks match with condidence >= 1 and zero offset'.
I'm only worrying that soon that options window will be so huge it won't fit on screen

Well it's not my intention to have a new mode added, because as you pointed out, it will quickly get out of control. What I'm after is maybe an advanced option that can be enabled that may be named something like "Don't consider aditional offsets for AR verification". Obviously this switch should be tied only to the "Encode only if" option.

I also have another bug report for you.

Check out the ouput for arcue.exe (both versions)

CODE

Checking AccurateRip database

Track   Ripping Status          [Disc ID: 0043e4fe-7c128c1b]

1      Accurately Ripped    (confidence 200)     [adb68f0f]
2      Accurately Ripped    (confidence 200)     [58331972]
3      Accurately Ripped    (confidence 200)     [3bcd3e3b]
4      Accurately Ripped    (confidence 200)     [31b8eb99]
5      Accurately Ripped    (confidence 200)     [04ea6254]
6      Accurately Ripped    (confidence 200)     [3f523f33]
7      Accurately Ripped    (confidence 200)     [dba3a427]
8      Accurately Ripped    (confidence 200)     [a1d91192]
9      Accurately Ripped    (confidence 200)     [06a8e557]
10     Accurately Ripped    (confidence 200)     [b20b75b4]
11     Accurately Ripped    (confidence 200)     [5e8a1fe6]
12     Accurately Ripped    (confidence 200)     [7ec3b3f2]
13     Accurately Ripped    (confidence 200)     [f8067b7a]
14     Accurately Ripped    (confidence 200)     [eb8d5713]
15     Accurately Ripped    (confidence 200)     [677bde1a]
16     Accurately Ripped    (confidence 200)     [3545f265]
17     Accurately Ripped    (confidence 200)     [5498403d]
18     Accurately Ripped    (confidence 200)     [e1ad245d]
19     Accurately Ripped    (confidence 200)     [139d6a70]
20     Accurately Ripped    (confidence 200)     [13205fec]
21     Accurately Ripped    (confidence 200)     [3e2a5e47]
22     Accurately Ripped    (confidence 200)     [d4c48fd6]
23     Accurately Ripped    (confidence 200)     [59e081a6]
24     Accurately Ripped    (confidence 200)     [3dd1ab41]
25     Accurately Ripped    (confidence 200)     [1868316f]
26     Accurately Ripped    (confidence 200)     [6c35cfc5]
27     Accurately Ripped    (confidence 200)     [1f9a4378]

_______________________

All Tracks Accurately Ripped.

and the ouput from CUETools Update8, using both Verify methods.

CODE

[Disc ID: 0043e4fe-0542e71b-7c128c1b]
Track    [ CRC    ] Status
01    [00000000] Database access error PartialContent
02    [00000000] Database access error PartialContent
03    [00000000] Database access error PartialContent
04    [00000000] Database access error PartialContent
05    [00000000] Database access error PartialContent
06    [00000000] Database access error PartialContent
07    [00000000] Database access error PartialContent
08    [00000000] Database access error PartialContent
09    [00000000] Database access error PartialContent
10    [00000000] Database access error PartialContent
11    [00000000] Database access error PartialContent
12    [00000000] Database access error PartialContent
13    [00000000] Database access error PartialContent
14    [00000000] Database access error PartialContent
15    [00000000] Database access error PartialContent
16    [00000000] Database access error PartialContent
17    [00000000] Database access error PartialContent
18    [00000000] Database access error PartialContent
19    [00000000] Database access error PartialContent
20    [00000000] Database access error PartialContent
21    [00000000] Database access error PartialContent
22    [00000000] Database access error PartialContent
23    [00000000] Database access error PartialContent
24    [00000000] Database access error PartialContent
25    [00000000] Database access error PartialContent
26    [00000000] Database access error PartialContent
27    [00000000] Database access error PartialContent

N.