Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1920909 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #325 –
Quote from: Gregory S. Chudov on
Quote from: fillip on
what I would request would be less interference with the existing tags (e.g. PUBLISHER turns into ORGANIZATION). and maybe the availability to just scan TAKs with embedded CUEs ...

I'm afraid PUBLISHER turns into ORGANIZATION due to the lack of interference  It also depends on the player.
Tag mapping is a total mess.
I just don't want to deal with it in cue tools, except for basic tags (Artist/Title/etc), which i handle through external taglibsharp.
The rest of the tags i just copy as they are. That means, that there's no interference when you convert flac to flac or ape to ape(wv,tak).
Your smart music player however can have it's own thoughs about tags mapping and give a different meaning to a tag with the same name, depending on the file format, which i personaly find insane.

so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #326 –
Quote from: fillip on
so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane

I think this is getting a bit off topic now, since Gregory already stated he doesn't want to mess with tag conversion... but looking at the chart he linked, the PUBLISHER tag field in Vorbis (FLAC) tags is there, but your FLAC files don't use it. So I t think the reason why you are having problems is because you really meant the ORGANIZATION tag field and not PUBLISHER in your Vorbis comment. If "PUBLISHER" turns into "ORGANIZATION" in foobar2000 after you've converted from FLAC to TAK, it can only mean that the original tag is ORGANIZATION and fb2k maps Vorbis/ORGANIZATION to PUBLISHER. But since CUE Tools names the APEv2 tag field ORGANIZATION (which doesn't officially exist as a standard?), foobar2000 will not remap it to PUBLISHER anymore when reading the APEv2 tag, for fb2k there is no official or unofficial standard APEv2/ORGANIZATION, so it displays it as is.

I'm not very happy that there are three different tag systems for lossless files, Vorbis, APEv2 and iTunes, and to a lesser degree Matroska. And that foobar2000 has a very transparent way of mapping things (so that the user doesn't see what is going on in the background), isn't helping either. Actually that's the main reason why I keep tagging as simple as possible and limit its use to the bare essentials, otherwise it means "a lot of work that will result in much more work once something goes wrong". I'm mainly frustrated about how Vorbis Comments do it so differently from what most of the rest of the lossless files do (APEv2). It just sucks.

PS: Suggestion - how about adding a new tab in the advanced settings that deals with tagging and creating of cue/log files? The "CUETools/General" section gets a bit crowded. All tagging and metadata related stuff should get its own tab, maybe unless it's more related to AR (writing AR log/tags settings should stay where they are?).

Also I can't figure out how to only write two tag fields when creating an embedded CD image: "CUESHEET" and "LOG". I let foobar2000 write all the other tag fields anyway.

And how do I disable writing of "ACCURATERIPID" to the tag and cue sheet, but still writing the AR log to a file?

What I currently do is to delete all tag fields except CUESHEET and LOG and then add another tag field with the contents of the accurip file to the tag, naming it ACCURIP. After that I'll load the audio file into foobar2000 and let it do the rest, which is actually only replaygaining the album.

I guess that when you ask 10 people how they like to tag their audio files then you will get 10 different answers. Do you think you can make the tagging more modular in some way? Have placeholders for certain key files (cue sheet, eac log, ar log) and placeholders for certain important metadata like the artist, album, year, and so on, but also AR results. Then people could create/edit/load/save profiles in CUETools. Certain tag field name standards or profiles could be hardcoded into CUETools in order to give newcomers some guidance.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #327 –
Quote from: Fandango on
Quote from: fillip on
so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane

I think this is getting a bit off topic now, since Gregory already stated he doesn't want to mess with tag conversion... but looking at the chart he linked, the PUBLISHER tag field in Vorbis (FLAC) tags is there, but your FLAC files don't use it. So I t think the reason why you are having problems is because you really meant the ORGANIZATION tag field and not PUBLISHER in your Vorbis comment. If "PUBLISHER" turns into "ORGANIZATION" in foobar2000 after you've converted from FLAC to TAK, it can only mean that the original tag is ORGANIZATION and fb2k maps Vorbis/ORGANIZATION to PUBLISHER. But since CUE Tools names the APEv2 tag field ORGANIZATION (which doesn't officially exist as a standard?), foobar2000 will not remap it to PUBLISHER anymore when reading the APEv2 tag, for fb2k there is no official or unofficial standard APEv2/ORGANIZATION, so it displays it as is.

I'm using "Publisher=PUBLISHER" in the foobar standard-tag-field options and most of the time I created the tag, so that would mean that foobar creates ORGANIZATION instead of PUBLISHER but treats it as such in FLAC, but not for APEV2 tagging ... doesn't that seem unlikely?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #328 –
i appreciate this app and i dont mean to be an ass or anything but i totally dont like the direction the UI is going in for the new beta. 1.9.5a behaved better and it was much faster.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #329 –
I had some trouble with the new filename corrector in the beginning, I still think the old "drag & drop" was faster, so I still use 1.9.5a personnaly. I can live with the new one witch highlight the cue directory as a "radio button" when you drag & drop cue in it now. But I don't think it's of any use to highlight the cue directory in the tree, just to fix the filename within the cue. It's not handy when you drop hundreds of cue & it's slower. In the end, I think the new version targets other users (beginners) than the old version, so I would like to still have a place in the interface where I could drop .cue without caring for any setting & without having them selected in the tree. I don't like the new filename corrector but it still does the job so if Gregory likes it, I don't care I will use the old version simply. I think you're a little unfair with Gregory, he does quite a good job. Not everything is bad in the change, for exemple having the offset in "extra" instead of "advanced settings" is faster. So it greatly depends on what you use & how you use it.

For me the biggest actual problem is the display of the "fake pressing number" on the right within the accurip log, which make many tangled logs un-understandable if you don't have a degree in "cuetools logs exegesis". Actually I refrain myself from scanning my whole collection just because I want logs without those useless & missleading numbers & I don't want to re-scan my whole collection twice if ever they would get removed in the next version which I highly hope.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #330 –
Quote from: dannymichel on
i appreciate this app and i dont mean to be an ass or anything but i totally dont like the direction the UI is going in for the new beta. 1.9.5a behaved better and it was much faster.

We can only guess what exactly you don't like and how how the speed difference shows up. Your comment doesn't provide anything that would help Gregory in the development.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #331 –
Quote from: sauvage78 on
For me the biggest actual problem is the display of the "fake pressing number" on the right within the accurip log, which make many tangled logs un-understandable if you don't have a degree in "cuetools logs exegesis".

I don't really understand what is going on when the tracks in the same album are "coming from" several different pressings even though they are all individually detected as accurate. Does that mean that I have an unsubmitted pressing in which some of the tracks have "skewed" differently than the other tracks?

However, personally, I would like to be able to see all possible information. Though some of the logs I have received have been quite odd, but maybe even these can help to understand a specific case better. Perhaps "full logging" could be an optional mode and the default mode could provide less information (something like EAC's AR component provides).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #332 –
It means nothing, the only way to detect a pressing is through its offset. This is not information, this is miss-information. The more different pressings (I mean CD with different offset) are submitted to the database the more this information is likely to be false (tangled), specially if the first guy who submitted result didn't rip all tracks or couldn't accurately rip some track. I don't know exactly how these numbers are generated, I think (guess) its related to the first submission for each offset. All I know is that I discovered that this information is wrong (tangled) several time.

This information looks like as if it is correct in most case only because most of the time, the first guy who rip the CD & submit, rips all tracks & rip them all accurately.
When this is not the case, (which happens quite often even if this is not the N°1 case) this information is wrong & means nothing. So overall as you cannot rely on it & it shouldn't be used.

Edit:
See this post to understand how this can happen: (Possible Explanation)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #333 –
I tried to understand the previous comments about this issue (also in the splitted thread on the CD Hardware/Software board) but I'm not sure if I succeeded.

It might help if Gregory could explain what part is provided directly by the database and what is calculated on the fly. Does the database hold the tracks from each different "pressing" together as a single "pressing" entity or are these pressing numbers created by CUETools?

Here is an example of my odd logs:

Code: [Select]
[Verification date: 2009-03-23 22:09:21]
[Disc ID: 00092e51-00300fb9-5608c006]
Track	[ CRC    ] Status
 01	[9cb22a62] (00/78) No matches
 02	[6d301741] (00/79) No matches
 03	[3fc14c22] (00/80) No matches
 04	[8727ea13] (00/79) No matches
 05	[28c01b9b] (00/76) No matches
 06	[9d00ea66] (00/77) No matches
Offsetted by -582:
 01	[ad83ccbc] (14/78) Accurately ripped as in pressing(s) #2
 02	[20523f8d] (14/79) Accurately ripped as in pressing(s) #3
 03	[95c1e7a5] (14/80) Accurately ripped as in pressing(s) #3
 04	[2fc2af69] (14/79) Accurately ripped as in pressing(s) #3
 05	[fc043d57] (14/76) Accurately ripped as in pressing(s) #3
 06	[a78852eb] (14/77) Accurately ripped as in pressing(s) #2
Offsetted by -53:
 01	[fd689a4d] (08/78) Accurately ripped as in pressing(s) #7
 02	[d2be27cb] (08/79) Accurately ripped as in pressing(s) #7
 03	[edb4cdb1] (08/80) Accurately ripped as in pressing(s) #7
 04	[ea191ec9] (08/79) Accurately ripped as in pressing(s) #7
 05	[b7738654] (08/76) Accurately ripped as in pressing(s) #7
 06	[dfdfe135] (08/77) Partial match to pressing(s) #7 
Offsetted by 68:
 01	[7c131b76] (16/78) Accurately ripped as in pressing(s) #1
 02	[ad493693] (16/79) Accurately ripped as in pressing(s) #2
 03	[b7a2c9cb] (16/80) Accurately ripped as in pressing(s) #2
 04	[883a71e8] (17/79) Accurately ripped as in pressing(s) #2
 05	[a4cb0293] (16/76) Accurately ripped as in pressing(s) #2
 06	[691fa4d2] (16/77) Accurately ripped as in pressing(s) #1
Offsetted by 74:
 01	[d8db5fba] (00/78) No matches
 02	[5b13d5bb] (00/79) No matches
 03	[7d4d1c94] (02/80) Partial match to pressing(s) #9 
 04	[f56651c4] (00/79) No matches
 05	[caff77c9] (00/76) No matches
 06	[431ab8ef] (00/77) No matches
Offsetted by 81:
 01	[7ff523d4] (02/78) Accurately ripped as in pressing(s) #9
 02	[b9a6ffed] (02/79) Accurately ripped as in pressing(s) #9
 03	[7a579054] (00/80) No matches
 04	[2dceefb9] (02/79) Accurately ripped as in pressing(s) #9
 05	[03ab743f] (02/76) Accurately ripped as in pressing(s) #8
 06	[14c94cae] (02/77) Accurately ripped as in pressing(s) #9
Offsetted by 86:
 01	[bd100a21] (02/78) Accurately ripped as in pressing(s) #8
 02	[6b09c225] (02/79) Accurately ripped as in pressing(s) #8
 03	[10808ce5] (03/80) Accurately ripped as in pressing(s) #8
 04	[14e07201] (02/79) Accurately ripped as in pressing(s) #8
 05	[6bbe2931] (00/76) No matches
 06	[f27ed8cc] (02/77) Accurately ripped as in pressing(s) #8
Offsetted by 349:
 01	[b90545bb] (17/78) Accurately ripped as in pressing(s) #6
 02	[8b0cda86] (17/79) Accurately ripped as in pressing(s) #6
 03	[09e0b05a] (17/80) Accurately ripped as in pressing(s) #6
 04	[11552584] (17/79) Accurately ripped as in pressing(s) #6
 05	[567494d3] (17/76) Accurately ripped as in pressing(s) #6
 06	[33fe9a9d] (17/77) Accurately ripped as in pressing(s) #6
Offsetted by 369:
 01	[1565092e] (05/78) Accurately ripped as in pressing(s) #5
 02	[487f580c] (05/79) Accurately ripped as in pressing(s) #5
 03	[c7aa7ccd] (05/80) Accurately ripped as in pressing(s) #5
 04	[ab485c09] (05/79) Accurately ripped as in pressing(s) #5
 05	[1b660552] (05/76) Accurately ripped as in pressing(s) #5
 06	[c114b785] (05/77) Accurately ripped as in pressing(s) #5
Offsetted by 387:
 01	[bc4e18ec] (00/78) No matches
 02	[f14ec4f1] (00/79) No matches
 03	[49f717a1] (05/80) Partial match to pressing(s) #4 
 04	[e6d597c9] (00/79) No matches
 05	[06f42509] (00/76) No matches
 06	[6414dc27] (00/77) No matches
Offsetted by 394:
 01	[593717f7] (05/78) Accurately ripped as in pressing(s) #3
 02	[e9b6c69c] (05/79) Accurately ripped as in pressing(s) #4
 03	[1a921d5a] (00/80) No matches
 04	[0ad10042] (05/79) Accurately ripped as in pressing(s) #4
 05	[372b4c98] (05/76) Accurately ripped as in pressing(s) #4
 06	[d8ad992a] (05/77) Accurately ripped as in pressing(s) #3
Offsetted by 537:
 01	[3d3aebba] (00/78) No matches
 02	[38ad56e8] (00/79) No matches
 03	[5820b831] (10/80) Partial match to pressing(s) #1 
 04	[ca96438f] (00/79) No matches
 05	[37e1f4c6] (00/76) No matches
 06	[ea043cff] (00/77) No matches
More than 10 offsets match!

Track	[ CRC32  ]	[W/O NULL]	
 --	[4A0FBF46]	[2AED3505]	
 01	[4E079B87]	[E9C376E3]	
 02	[88913FA4]	[11DB04B0]	
 03	[6EFE0C70]	[D3B2611C]	
 04	[3B7423DB]	[3084F142]	
 05	[57E9EBA1]	[F6207931]	
 06	[26E16D68]	[1511D14D]
I ripped it seven years ago to a single file & cue sheet and I didn't have offset correction set in EAC (at that time I didn't have any of the listed reference dics). Usually I have also the EAC logs stored, but in this case it is missing.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #334 –
Your rip is accurate, the problem is that if you would trust the #pressing information you would think the one "Offsetted by 349 tied to pressing #6" or the one "Offsetted by 369 tied to pressing #5" are the "best" ones, & you would reject the one "Offsetted by 68 which is tied to both pressing #1 tangled with pressing #2" & the one "Offsetted by -582 which is tied both to pressing #2 tangled with pressing #3"", this is NOT TRUE your CD could very well be  from the pressing "Offsetted by 68" or from the pressing "Offsetted by -582". In fact, it is even more likely that your CD is from the pressing "Offsetted by 68" or from the pressing "Offsetted by -582" than from the pressing "Offsetted by 369", because the accuraterip count is higher (14 or 17 Vs. only 5) so obviously these pressings have been sold much more.

A match is a match, all counts. All matches on the same offset is a complete pressing, all pressing counts too. The actual display exclude some perfectly accurate pressing.

So the pressing "Offsetted by 68" or "Offsetted by -582" are not worst than the pressing "Offsetted by 349" & "Offsetted by 369". It is just as accurate, which is very missleading due to the way it is displayed right now.

Edit: forgot the pressing "Offsetted by -582" which is good too

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #335 –
I'm going to post a few other logs that look suspicous.

Here's the first.
Code: [Select]
[Verification date: 2009-03-30 17:48:20]
[Disc ID: 000c56a6-005d0a96-75090d09]
Pregap length 00:00:32.
Track	[ CRC    ] Status
 01	[3bcca92f] (19/29) Accurately ripped as in pressing(s) #1
 02	[82c425e1] (19/29) Accurately ripped as in pressing(s) #1
 03	[d2549a52] (19/29) Accurately ripped as in pressing(s) #1
 04	[33a116b6] (18/28) Accurately ripped as in pressing(s) #1
 05	[ff40280f] (19/29) Accurately ripped as in pressing(s) #1
 06	[cf15e913] (19/29) Accurately ripped as in pressing(s) #1
 07	[81538458] (19/29) Accurately ripped as in pressing(s) #1
 08	[2568846f] (19/28) Accurately ripped as in pressing(s) #1
 09	[4d06a4b6] (02/27) Accurately ripped as in pressing(s) #2

Track	[ CRC32  ]	[W/O NULL]	
 --	[4019831C]	[4F03B3DC]	
 01	[3375127F]	[BE1C3E54]	
 02	[65FD20F7]	[61605CCA]	
 03	[46D5A689]	[9A18CF9A]	
 04	[555F7FE6]	[D833D3B0]	
 05	[FD9DB432]	[5CFFBDF3]	
 06	[86CC84B2]	[FDBBDA9F]	
 07	[0ACB623E]	[631A4477]	
 08	[DA7EDF71]	[355118DE]	
 09	[85A2F23D]	[1CDCC758]
Apparently there is a different pressing that does not have a different offset and only the last track matches the tracks in this pressing.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #336 –
It might be that the last track is a bonus track, no ?

Edit2: Well, no, I don't think so. For me this rip is accurate anyway & that's the only thing you should worry about. It might sound strange that 17 guy wouldn't be able to rip the last track, the only question you should ask yourself is: is it impossible ? the answer is no, specially as it is the last track & last track can have trouble for various reason. (Edge of CD scratched or big offset & over-read)

Edit1: IMHO there should be a dedicated thread for cuetools logs because I feel like everyone hijack this thread with his logs almost everyday.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #337 –
I guess most people had trouble ripping the last track.
Sorry, a bit busy at the moment.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #338 –
Quote from: sauvage78 on
It might be that the last track is a bonus track, no ? (Edit: well no I don't think so.)

If would then be a different disc I think. Gregory is probably right.

EDIT

Though I still don't understand why the pressing #2 is not listed separately with its offset.

Quote
Edit: IMHO there should be a dedicated thread for cuetools logs because I feel like everyone hijack this thread with his logs almost everyday.

That depends on what is considered to be on topic here. Since some logs seem to be difficult to understand I think it is good to have a few different examples and explanations for them.

I assume the previous thread split was done because the discussion wandered a bit off-topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #339 –
Yes, Gregory is right. For me the second log shows how accuraterip thinks from a machine point of view, & not from our human point of view. If accuraterip tells you that it is this wrong then there is a logic way to understand it. Checksums are relentless, but again it shows that the #pressing numbers are meaningless. It only tells you that the first guy who ripped the CD failed on the last track ... what a usefull information

Your log wouldn't be less informative if it would look like this:

Quote
[Verification date: 2009-03-30 17:48:20]
[Disc ID: 000c56a6-005d0a96-75090d09]
Pregap length 00:00:32.
Track [ CRC ] Status
01 [3bcca92f] (19/29) Accurately ripped as in pressing(s) #1
02 [82c425e1] (19/29) Accurately ripped as in pressing(s) #1
03 [d2549a52] (19/29) Accurately ripped as in pressing(s) #1
04 [33a116b6] (18/28) Accurately ripped as in pressing(s) #1
05 [ff40280f] (19/29) Accurately ripped as in pressing(s) #1
06 [cf15e913] (19/29) Accurately ripped as in pressing(s) #1
07 [81538458] (19/29) Accurately ripped as in pressing(s) #1
08 [2568846f] (19/28) Accurately ripped as in pressing(s) #1
09 [4d06a4b6] (02/27) Accurately ripped as in pressing(s) #2

Track [ CRC32 ] [W/O NULL]
-- [4019831C] [4F03B3DC]
01 [3375127F] [BE1C3E54]
02 [65FD20F7] [61605CCA]
03 [46D5A689] [9A18CF9A]
04 [555F7FE6] [D833D3B0]
05 [FD9DB432] [5CFFBDF3]
06 [86CC84B2] [FDBBDA9F]
07 [0ACB623E] [631A4477]
08 [DA7EDF71] [355118DE]
09 [85A2F23D] [1CDCC758]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #340 –
Quote
Though I still don't understand why the pressing #2 is not listed separately with its offset.


Because it has the same offset & because it is the same pressing. As I tried to explain, #1 & #2 tells nothing except that ripper N°1 was the first guy who ripped the CD & he ripped track 1-8 accurately which were marked as pressing #1, then came the guy N°2 which ripped the CD accurately from track 1 to 9, as 1-8 were already marked as pressing #1, only the track 9 was marked as pressing #2. There is NOT two pressings.

This is a very missleading behavior for new users. Even knowing all this, in the first seconds, I was misslead thinking it might be due to a bonus track when I perfectly know that it would have a new ID if it would have a bonus track. So for a new user, this is just un-readable.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #341 –
It is likely that the drive is ripping the last track differently, (or was there an EAC bug a while back on some drives)? and 2 other people have the same drive & issue...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #342 –
As we are at strange logs examination, this one is not bad too, personnaly I don't understand how there can be such a huge confidence jump between tracks, even between tracks of the same pressing # number, it jumps up & down from 60 to 160 ... & not on the last track. It's a quite popular as it's a Bob Marley CD. If someone has a clue.


Code: [Select]
[Verification date: 03/04/2009 06:05:37]
[Disc ID: 00291c0e-01f054e3-c5115710]
Track	[ CRC	] Status
 01	[c0683278] (62/227) Accurately ripped as in pressing(s) #1
 02	[2e767ef0] (62/232) Accurately ripped as in pressing(s) #3
 03	[340d0ef4] (62/227) Accurately ripped as in pressing(s) #2
 04	[f7f61bc0] (61/225) Accurately ripped as in pressing(s) #2
 05	[ec15c042] (160/226) Accurately ripped as in pressing(s) #2
 06	[12f9bb59] (62/228) Accurately ripped as in pressing(s) #2
 07	[5ce044d3] (169/227) Accurately ripped as in pressing(s) #1
 08	[513de00d] (169/225) Accurately ripped as in pressing(s) #1
 09	[6dbd6dbf] (159/228) Accurately ripped as in pressing(s) #2
 10	[fe4dacdc] (162/229) Accurately ripped as in pressing(s) #2
 11	[ac98df80] (171/228) Accurately ripped as in pressing(s) #1
 12	[e09118dd] (63/229) Accurately ripped as in pressing(s) #3
 13	[ee8ecbd5] (171/227) Accurately ripped as in pressing(s) #1
 14	[020bf2d0] (72/225) Accurately ripped as in pressing(s) #3
 15	[99099da6] (82/225) Accurately ripped as in pressing(s) #1
 16	[fc8e0a5b] (148/220) Accurately ripped as in pressing(s) #1
Offsetted by -664:
 01	[2138fa35] (05/227) Accurately ripped as in pressing(s) #5
 02	[2f810237] (05/232) Accurately ripped as in pressing(s) #7
 03	[c2e6cefd] (05/227) Accurately ripped as in pressing(s) #4
 04	[0cefda2d] (05/225) Accurately ripped as in pressing(s) #5
 05	[e2ff9a1b] (05/226) Accurately ripped as in pressing(s) #4
 06	[b606540a] (05/228) Accurately ripped as in pressing(s) #5
 07	[ce4c3ba7] (05/227) Accurately ripped as in pressing(s) #3
 08	[ae59f662] (05/225) Accurately ripped as in pressing(s) #3
 09	[f18c36d9] (05/228) Accurately ripped as in pressing(s) #4
 10	[49bab45c] (05/229) Accurately ripped as in pressing(s) #4
 11	[b1d5fba8] (05/228) Accurately ripped as in pressing(s) #3
 12	[38b1b338] (05/229) Accurately ripped as in pressing(s) #5
 13	[006c5060] (05/227) Accurately ripped as in pressing(s) #3
 14	[637e31bc] (05/225) Accurately ripped as in pressing(s) #5
 15	[dc72779b] (05/225) Accurately ripped as in pressing(s) #4
 16	[e65d55f3] (05/220) Accurately ripped as in pressing(s) #5
Offsetted by -96:
 01	[6ab0a297] (02/227) Accurately ripped as in pressing(s) #4
 02	[7d4164a1] (02/232) Accurately ripped as in pressing(s) #6
 03	[e90c074f] (00/227) No matches
 04	[1c9d6271] (00/225) No matches
 05	[d735b49e] (00/226) No matches
 06	[504e79d5] (00/228) No matches
 07	[6f18acea] (00/227) No matches
 08	[e3733a7a] (00/225) No matches
 09	[54118eb0] (00/228) No matches
 10	[567644c3] (00/229) No matches
 11	[ff77dddd] (00/228) No matches
 12	[4f8bbc30] (00/229) No matches
 13	[68cf3eb6] (00/227) No matches
 14	[9f17732b] (00/225) No matches
 15	[eef95ce2] (00/225) No matches
 16	[5a248e77] (00/220) No matches
Offsetted by 6:
 01	[42c6f153] (00/227) No matches
 02	[e3d3dbde] (00/232) No matches
 03	[c3513ff2] (00/227) No matches
 04	[bbaa0273] (00/225) No matches
 05	[3925935f] (00/226) No matches
 06	[374da903] (00/228) No matches
 07	[9c44472e] (00/227) No matches
 08	[d3564913] (00/225) No matches
 09	[cc47d4c1] (02/228) Accurately ripped as in pressing(s) #5
 10	[9f42a4dc] (00/229) No matches
 11	[cd15fc09] (00/228) No matches
 12	[70dea4d3] (00/229) No matches
 13	[aa87fd23] (00/227) No matches
 14	[b69e62f0] (00/225) No matches
 15	[973fb11c] (00/225) No matches
 16	[48a5fa54] (00/220) No matches
Offsetted by 10:
 01	[b4318618] (53/227) Partial match to pressing(s) #2 
 02	[95c46804] (53/232) Partial match to pressing(s) #4 
 03	[6d53d08d] (51/227) Partial match to pressing(s) #3 
 04	[8000d736] (50/225) Partial match to pressing(s) #3 
 05	[eb4a08db] (51/226) Accurately ripped as in pressing(s) #3
 06	[78b47cac] (53/228) Partial match to pressing(s) #3 
 07	[f99d7f7d] (53/227) Accurately ripped as in pressing(s) #2
 08	[e0a0ecdd] (51/225) Partial match to pressing(s) #2 
 09	[47e2b102] (52/228) Accurately ripped as in pressing(s) #3
 10	[01e3f387] (52/229) Accurately ripped as in pressing(s) #3
 11	[cd20f248] (52/228) Partial match to pressing(s) #2 
 12	[e97b8e05] (52/229) Partial match to pressing(s) #4 
 13	[8c0b992a] (51/227) Partial match to pressing(s) #2 
 14	[9db4fc4e] (50/225) Partial match to pressing(s) #4 
 15	[57fa151c] (50/225) Accurately ripped as in pressing(s) #3
 16	[b7a5bee3] (49/220) Accurately ripped as in pressing(s) #2

Track	[ CRC32  ]	[W/O NULL]	[  LOG   ]
 --	[1A37DB61]	[439E67C3]	 W/O NULL 
 01	[DD2B55F2]	[E0ED588B]	
 02	[0081AF91]	[4193E65E]	
 03	[0106732F]	[5ACBED08]	
 04	[4F3F94CE]	[C93AAD20]	
 05	[218ABBCF]	[0B8146F4]	
 06	[3BD0E43B]	[7A54B533]	
 07	[35F586BD]	[B6E6DBB9]	
 08	[A6AE7349]	[582E60E1]	
 09	[7579B2D1]	[1C33704A]	
 10	[6F08BD5E]	[033EEEA6]	
 11	[9D02EBB7]	[AC6DF490]	
 12	[07AD8EBD]	[42A87F01]	
 13	[4A3112D6]	[E57798EF]	
 14	[4B1C1CE3]	[1B14401D]	
 15	[98B0FBAF]	[1F0E527F]	
 16	[9E89FEEE]	[18753F8F]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #343 –
You would have to rip that CD in EAC of dBpoweramp to check those tracks out, to see if that jump is there.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #344 –
Alex B, is your drive configured as being able to overread in EAC?

Toggle the setting and see if you get a different result.

With some discs, the last two frames of non-null samples will be repeated due to a bug in EAC when overreading is disabled.  Because most people have this setting disabled, errant data will constitute the majority of submissions when this bug occurs.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #345 –
Quote from: Gregory S. Chudov on
Quote from: NightOwl on
Can an option be added so that CUE Tools goes back to the previous behaviour with "Verify, don't encode" when a CD is not in the AccurateRip database?

Previously, CRCs were only computed when a CD was in the AccurateRip database.

By the way, why does the "Select the best match" pop-up window appear to choose a log file when there is only one log file in a directory? The fully-qualified log file name is already shown and there is nothing else to choose in the drop-down list.


Done. Check out 1.9.5, it has two verify modes.

"Select the best match" pop-up window appears if there are several log files or log file name doesn't match cue sheet name.
You are asked to confirm that you want to use this log for verification/encoding.
In 1.9.5 it is a bit more informative and pretty


Thank you very much, Gregory. I've been using 1.9.5 since it came out (Feb 23) and today I upgraded to 1.9.5a (gee, I'm just over a month late now  ).

The log file issue has not been fixed (I have used 1.9.5 extensively and I just verified the problem on 1.9.5a). I specify "Verify AR only" but CUE Tools still prompts me for the name of the log file. I did not specify "Verify AR + CRCs" so the log file should not be required. Once "Verify AR only" has finished, the .accurip output file has the LOG column at the bottom completely filled in. I compared the .accurip output files for "Verify AR only" against "Verify AR + CRCs" and they are identical (except for the time of day, of course). Why do the two verify modes behave the same? If I specify "Verify AR only" I expect the CRCs in the log file as well as the log file itself to be ignored.

Nobody mentioned this so far, but I like the "CUE" icon you added in 1.9.5.

Ah, thank you for explaining the "Select the best match" pop-up window. I'll make sure my cue and log files have the same name. Yes, in 1.9.5 and 1.9.5a it is a bit more informative and pretty. Thank you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #346 –
I joined to ask what offset X, files accurately ripped means? Should my files be offset by 6 bits and then the will be accurately ripped? Is there an option to detect files as they are without offsetting them? Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.
great work!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #347 –
Quote
Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.


I strictly disagree with this as paths changes with time, maybe Artist/Album from freeDB, but no folder name & path, because some people have very strange way of naming their files.
All paths within EAC logs looks different for each guy, only the Artist/Album from freeDB in the first lines remains clean no matter the naming scheme. I am very happy with how it works right now, maths only no litteracy. Also if you add stuff like Folder: or Path: ... soon newbies will ask you to translate these & accurip logs will become less standardized.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #348 –
Quote from: sauvage78 on
Quote
Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.


I strictly disagree with this as paths changes with time, maybe Artist/Album from freeDB, but no folder name & path, because some people have very strange way of naming their files.
All paths within EAC logs looks different for each guy, only the Artist/Album from freeDB in the first lines remains clean no matter the naming scheme. I am very happy with how it works right now, maths only no litteracy. Also if you add stuff like Folder: or Path: ... soon newbies will ask you to translate these & accurip logs will become less standardized.

I didn't mean the accurate rip log. I meant the main log i.e FolderName\... not present in database. Its very difficult to filter out the information in a glance...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #349 –
When trying to open CUEtools a second time while another encoding is already in progress, the second instance crashes without a useful message (like "you can only run it one time at once")...
audiophile // flac & wavpack, mostly // using too many audio players