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 1911122 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 #300 –
Thanks for update,  filetree is now working in XP pro. 
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.
So I have to drag and drop again to do a verify.
I would like if it stayed the dropped directory until I click in the tree.

Another point of convenience:
I store my albums in flac or ape files, most of my cue-files are based on wav-files.
It would be very handy if cuetools would apply 'correct filenames' if it encounters a cuesheet in which the extension doesn't match 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #301 –
Suggestion: If I pass a .cue file as a parameter to CUETools, it should be used automatically.

audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #302 –
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?
A friend of mine started using squeezecenter and that does not understand embedded cuesheets very well. So now I want to extract the cuesheets from these images. Afaik they are vorbis comments named CUESHEET.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #303 –
hey there, I'm using 2.0.1 experimental and it turns out to work really good. no crash or bug happened till now  like the file tree. 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 ... have a lot of old images here in TAK and I would like to check them against accuraterip

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #304 –
Quote from: sauvage78 on
But as long as accuraterip logs will be so tricky to understand, a summary will save a headache to a lot of people IMHO.

The summary cannot be a simple yes or no anyway. But i will think what can be done.
Have you seen the summary in the batch mode? It shows a sum of confidence for all offsets.
I can add it to the .accurip logs.

I like the idea of configurable .accurip file name.

Quote from: sauvage78 on
Last question, I noticed that "Partial match to pressing(s)" happens very often on the last track & my own ripping experience learned me that problem with scratches often happens on the last track too. Does it always means the rip is bad ? Is there any possibility that these rips could be good. I ask because I am gonna delete these rips to save some space. From my understanding of accuraterip these rips are inaccurate but I wonder if there could be some exception/special case that I could have forget. So I'd rather ask before I delete them. If you look at popular CD with lot of accurate results, the total is almost always lower on the last track.

There is one exception. If the last track is "partial match" in the pressing with high offset (usually 2000+), this just means that a few milliseconds of sound were lost at the end of the disc. This happens more often if your drive offset is high too. There always are some samples lost at the end, but AccurateRip ignores last 2940 samples, so we still get a match if drive offset + pressing offset were not that high.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #305 –
Quote from: Tigerman on
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.

For now, i would sugest dropping it to a file tree instead of input text box.

Quote from: Tigerman on
I store my albums in flac or ape files, most of my cue-files are based on wav-files.
It would be very handy if cuetools would apply 'correct filenames' if it encounters a cuesheet in which the extension doesn't match 

You don't have to correct filenames if you are going to use this cue sheet in cuetools.
Just make sure "Advanced settings->Locate audio files if misisng" is turned on.
If you need to correct cue sheets for use with fb2k or something else, well, there's a 'correct filenames' action.
You want to automaticly modify cue sheets when verifying them? What's the point?
I prefer programs which are predictable, do what they are told to do, and don't try to be too clever.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #306 –
Quote from: tuxman on
Suggestion: If I pass a .cue file as a parameter to CUETools, it should be used automatically.

Define 'used'.
Right now it puts it into input box, so all you have to do to actually use it is select an action and press 'go'.
I don't think running a random (previously selected) action immediately is a good idea.
Did you try "cuetools.exe /verify <file.cue>"?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #307 –
Quote from: Scidd0w on
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?

Are there any objections to make it a part of 'create cue' action?
Right now it creates dummy cue sheets for file-per-track images, but what if it would also extract embedded cue sheets?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #308 –
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.

TAKs with embedded CUEs were supposed to be supported, i'm afraid i've just broken it in 2.01  Oops.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #309 –
Quote from: greynol on
There are situations where ripping a disc can result in an error of repeated samples that causes all subsequent tracks to be offset by a constant amount.  Disregarding offsets in a summary can give a false impression that all but one track was ok.

Well, if we don't care about offsets and only care about the audio bits, all but one track are truly ok in this case
Especially if we view the album as a collection of tracks, not as solid image.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #310 –
Let's take an example that is tricky to understand for a newbie: this rip is accurate because all track matches to a CRC somewhere inside the log, but you cannot know that it is accurate as long as you don't take some precious time to analyse it. First the offset don't match, so for a newbie it seems inaccurate. Then when you realize that each track is accurate somewhere, you realize that there is no pressing in database where all track (which are all accurate somewhere) matches the same offset. Track 12 & 13 are specially tricky to understand. If there would be a summary of the total matches no matter the offset (like EAC does I think) with a short sentence of conclusion in front of the actual result sorted by offset it would much more easier to understand.

Code: [Select]
[Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
Track	[ CRC	] Status
 01	[3f2c9a5d] (00/71) No matches
 02	[7a2b32fe] (00/72) No matches
 03	[ba21c9d3] (00/74) No matches
 04	[caf89a47] (00/73) No matches
 05	[0f4ae166] (00/72) No matches
 06	[fdd1ffec] (00/72) No matches
 07	[5701a8a7] (00/71) No matches
 08	[77edd59f] (00/71) No matches
 09	[710af6d9] (00/70) No matches
 10	[0cc3909c] (00/71) No matches
 11	[2af70c17] (00/73) No matches
 12	[98b675df] (00/73) No matches
 13	[1e6be6e0] (00/72) No matches
 14	[06ab37c2] (00/71) No matches
 15	[12b42c24] (00/73) No matches
 16	[93847f7f] (00/67) No matches
Offsetted by 526:
 01	[55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02	[61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03	[967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04	[b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05	[80427398] (03/72) Accurately ripped as in pressing(s) #2
 06	[ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07	[ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08	[9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09	[1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10	[926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11	[1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12	[1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13	[f33c3520] (00/72) No matches
 14	[6c1e076a] (00/71) No matches
 15	[52c61e16] (00/73) No matches
 16	[18468c81] (00/67) No matches
Offsetted by 562:
 01	[9197ef79] (00/71) No matches
 02	[631546ee] (00/72) No matches
 03	[8a4ebb3f] (00/74) No matches
 04	[8c351787] (00/73) No matches
 05	[748602f4] (00/72) No matches
 06	[408fd5ee] (00/72) No matches
 07	[8d438049] (00/71) No matches
 08	[e864916d] (00/71) No matches
 09	[a862b093] (00/70) No matches
 10	[8b0940e4] (00/71) No matches
 11	[3b97117e] (00/73) No matches
 12	[5f9d0c95] (00/73) No matches
 13	[b9a5fc97] (03/72) Partial match to pressing(s) #2 
 14	[1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2
 15	[0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2
 16	[aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2
Offsetted by 624:
 01	[4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02	[8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03	[91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04	[532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05	[993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06	[a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07	[f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08	[c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09	[5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10	[e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11	[82576123] (70/73) Accurately ripped as in pressing(s) #1
 12	[ec896e32] (70/73) Partial match to pressing(s) #1 
 13	[d23ebe95] (00/72) No matches
 14	[908a0d02] (00/71) No matches
 15	[6d4fc9b4] (00/73) No matches
 16	[7bf5e58f] (00/67) No matches
Offsetted by 660:
 01	[8a19cc35] (00/71) No matches
 02	[912a0d5e] (00/72) No matches
 03	[859cb7cb] (00/74) No matches
 04	[29cdc2c7] (00/73) No matches
 05	[8d76d052] (00/72) No matches
 06	[1ea601a0] (00/72) No matches
 07	[b20e4c9b] (00/71) No matches
 08	[12c79f0b] (00/71) No matches
 09	[e33b533d] (00/70) No matches
 10	[da733dec] (00/71) No matches
 11	[1bc963e9] (00/73) No matches
 12	[49fe0a7f] (00/73) No matches
 13	[3a099b36] (69/72) Accurately ripped as in pressing(s) #1
 14	[3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1
 15	[28b16190] (70/73) Accurately ripped as in pressing(s) #1
 16	[0e4b354b] (64/67) Accurately ripped as in pressing(s) #1

Track	[ CRC32  ]	[W/O NULL]	
 --	[1EE5D6F8]	[3FA0CF2E]	
 01	[8D3C25ED]	[9735BA9D]	
 02	[CAD69A48]	[86DA87A4]	
 03	[3B823160]	[86B00269]	
 04	[F33ECAE3]	[20CDDE60]	
 05	[A38A856D]	[06776367]	
 06	[7A790E1C]	[21369F0E]	
 07	[83B74D2B]	[E2D4B016]	
 08	[49B7D546]	[44D48885]	
 09	[A1D45191]	[BF682C61]	
 10	[7CD2046A]	[2ED76E23]	
 11	[8A053B65]	[53EFC9B1]	
 12	[E07850DD]	[9B74BA07]	
 13	[C1791415]	[01E27F3A]	
 14	[4E675017]	[7A5EBA97]	
 15	[C5D95A38]	[83036201]	
 16	[D5F63E99]	[817A1E4F]

Here is a mockup of the same log so that you understand what I mean:

Code: [Select]
[color=#FF0000][Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
------------------------------------------------------------------
AccurateRip summary

Offsetted by (All offsets)
Track	[ CRC	] Status
 01	[CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 02	[CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 03	[CRC of Actual Data] (Sum of total accurate rip for the track/74) accurately ripped (confidence X) no matter the offset/pressing
 04	[CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 05	[CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 06	[CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 07	[CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 08	[CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 09	[CRC of Actual Data] (Sum of total accurate rip for the track/70) accurately ripped (confidence X) no matter the offset/pressing
 10	[CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 11	[CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 12	[CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 13	[CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 14	[CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 15	[CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 16	[CRC of Actual Data] (Sum of total accurate rip for the track/67) accurately ripped (confidence X) no matter the offset/pressing
 
All tracks accurately ripped/No track could be verified as accurately ripped/Track XYZ couldn't be verified as accurately ripped. (You may have a different pressing than the ones in database)
----------------------------------------------------------------

No offset applied: (Actual Data)[/color]
Track	[ CRC	] Status
 01	[3f2c9a5d] (00/71) No matches
 02	[7a2b32fe] (00/72) No matches
 03	[ba21c9d3] (00/74) No matches
 04	[caf89a47] (00/73) No matches
 05	[0f4ae166] (00/72) No matches
 06	[fdd1ffec] (00/72) No matches
 07	[5701a8a7] (00/71) No matches
 08	[77edd59f] (00/71) No matches
 09	[710af6d9] (00/70) No matches
 10	[0cc3909c] (00/71) No matches
 11	[2af70c17] (00/73) No matches
 12	[98b675df] (00/73) No matches
 13	[1e6be6e0] (00/72) No matches
 14	[06ab37c2] (00/71) No matches
 15	[12b42c24] (00/73) No matches
 16	[93847f7f] (00/67) No matches
Offsetted by 526:
 01	[55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02	[61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03	[967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04	[b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05	[80427398] (03/72) Accurately ripped as in pressing(s) #2
 06	[ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07	[ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08	[9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09	[1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10	[926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11	[1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12	[1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13	[f33c3520] (00/72) No matches
 14	[6c1e076a] (00/71) No matches
 15	[52c61e16] (00/73) No matches
 16	[18468c81] (00/67) No matches
Offsetted by 562:
 01	[9197ef79] (00/71) No matches
 02	[631546ee] (00/72) No matches
 03	[8a4ebb3f] (00/74) No matches
 04	[8c351787] (00/73) No matches
 05	[748602f4] (00/72) No matches
 06	[408fd5ee] (00/72) No matches
 07	[8d438049] (00/71) No matches
 08	[e864916d] (00/71) No matches
 09	[a862b093] (00/70) No matches
 10	[8b0940e4] (00/71) No matches
 11	[3b97117e] (00/73) No matches
 12	[5f9d0c95] (00/73) No matches
 13	[b9a5fc97] (03/72) Partial match to pressing(s) #2 
 14	[1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2
 15	[0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2
 16	[aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2
Offsetted by 624:
 01	[4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02	[8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03	[91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04	[532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05	[993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06	[a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07	[f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08	[c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09	[5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10	[e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11	[82576123] (70/73) Accurately ripped as in pressing(s) #1
 12	[ec896e32] (70/73) Partial match to pressing(s) #1 
 13	[d23ebe95] (00/72) No matches
 14	[908a0d02] (00/71) No matches
 15	[6d4fc9b4] (00/73) No matches
 16	[7bf5e58f] (00/67) No matches
Offsetted by 660:
 01	[8a19cc35] (00/71) No matches
 02	[912a0d5e] (00/72) No matches
 03	[859cb7cb] (00/74) No matches
 04	[29cdc2c7] (00/73) No matches
 05	[8d76d052] (00/72) No matches
 06	[1ea601a0] (00/72) No matches
 07	[b20e4c9b] (00/71) No matches
 08	[12c79f0b] (00/71) No matches
 09	[e33b533d] (00/70) No matches
 10	[da733dec] (00/71) No matches
 11	[1bc963e9] (00/73) No matches
 12	[49fe0a7f] (00/73) No matches
 13	[3a099b36] (69/72) Accurately ripped as in pressing(s) #1
 14	[3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1
 15	[28b16190] (70/73) Accurately ripped as in pressing(s) #1
 16	[0e4b354b] (64/67) Accurately ripped as in pressing(s) #1

Track	[ CRC32  ]	[W/O NULL]	
 --	[1EE5D6F8]	[3FA0CF2E]	
 01	[8D3C25ED]	[9735BA9D]	
 02	[CAD69A48]	[86DA87A4]	
 03	[3B823160]	[86B00269]	
 04	[F33ECAE3]	[20CDDE60]	
 05	[A38A856D]	[06776367]	
 06	[7A790E1C]	[21369F0E]	
 07	[83B74D2B]	[E2D4B016]	
 08	[49B7D546]	[44D48885]	
 09	[A1D45191]	[BF682C61]	
 10	[7CD2046A]	[2ED76E23]	
 11	[8A053B65]	[53EFC9B1]	
 12	[E07850DD]	[9B74BA07]	
 13	[C1791415]	[01E27F3A]	
 14	[4E675017]	[7A5EBA97]	
 15	[C5D95A38]	[83036201]	
 16	[D5F63E99]	[817A1E4F]

With such a log you know instanly if all track are ripped accurately somewhere within the log, & even better you can instantly search all logs for bad rips. No headache with offsets & tracks 12 & 13.

Edit1: Thks for the answers.
Edit2: I wrapped logs in quote instead of code ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #311 –
I just got done telling you that there can actually be a problem with your rip in these instances and that picking results from one pressing and then from another can be misleading.

Do you think I'm making it up?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #312 –
Well maybe it's even more tricky than what I understund ... sorry but there is no tutorial anywhere.  I understund your repeated sample problem, but it seems to happen more often than "some situations" then ... because I only tested something like 20-30 rips & I already have 3-4 of these situations. Also if it was a random number of repeated samples how could it match any other pressing, the probability seems low IMHO. But well maybe I understund something wrong.

Edit: Typo mixed offset/sample

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #313 –
oh !!! I just catched that offset 526 & offset 562 are both tied to pressing number 2, I first thought that  offset 526 was one pressing & offset 562 another pressing, I understand better what you meant now Greynol, Thks !!! Damned, this make logs even harder to understand if there can be two offsets for the same pressing

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #314 –
The more i think about it, the more i'm convinced that audio-CD is a flawed technology from the start. It just isn't digital enough. Which is not surprising, considering that at the time this technology was being developed, noone really thought that computers would be able to read them.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #315 –
Now that thks to greynol I understund this log better, I think that it shouldn't be reported this way, but this way:


Code: [Select]
[Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
Track	[ CRC	] Status
 01	[3f2c9a5d] (00/71) No matches
 02	[7a2b32fe] (00/72) No matches
 03	[ba21c9d3] (00/74) No matches
 04	[caf89a47] (00/73) No matches
 05	[0f4ae166] (00/72) No matches
 06	[fdd1ffec] (00/72) No matches
 07	[5701a8a7] (00/71) No matches
 08	[77edd59f] (00/71) No matches
 09	[710af6d9] (00/70) No matches
 10	[0cc3909c] (00/71) No matches
 11	[2af70c17] (00/73) No matches
 12	[98b675df] (00/73) No matches
 13	[1e6be6e0] (00/72) No matches
 14	[06ab37c2] (00/71) No matches
 15	[12b42c24] (00/73) No matches
 16	[93847f7f] (00/67) No matches
Offsetted by 526:
 01	[55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02	[61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03	[967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04	[b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05	[80427398] (03/72) Accurately ripped as in pressing(s) #2
 06	[ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07	[ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08	[9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09	[1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10	[926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11	[1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12	[1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13	[b9a5fc97] (03/72) Partial match to pressing(s) #2 
 14	[1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch
 15	[0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch
 16	[aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch

Offsetted by 624:
 01	[4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02	[8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03	[91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04	[532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05	[993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06	[a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07	[f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08	[c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09	[5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10	[e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11	[82576123] (70/73) Accurately ripped as in pressing(s) #1
 12	[ec896e32] (70/73) Partial match to pressing(s) #1 
 13	[3a099b36] (69/72) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 14	[3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 15	[28b16190] (70/73) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 16	[0e4b354b] (64/67) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch


Track	[ CRC32  ]	[W/O NULL]	
 --	[1EE5D6F8]	[3FA0CF2E]	
 01	[8D3C25ED]	[9735BA9D]	
 02	[CAD69A48]	[86DA87A4]	
 03	[3B823160]	[86B00269]	
 04	[F33ECAE3]	[20CDDE60]	
 05	[A38A856D]	[06776367]	
 06	[7A790E1C]	[21369F0E]	
 07	[83B74D2B]	[E2D4B016]	
 08	[49B7D546]	[44D48885]	
 09	[A1D45191]	[BF682C61]	
 10	[7CD2046A]	[2ED76E23]	
 11	[8A053B65]	[53EFC9B1]	
 12	[E07850DD]	[9B74BA07]	
 13	[C1791415]	[01E27F3A]	
 14	[4E675017]	[7A5EBA97]	
 15	[C5D95A38]	[83036201]	
 16	[D5F63E99]	[817A1E4F]

There shouldn't be two offset results for the same pressing, what do you think of it ? It is possible to correct this offset lags ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #316 –
I'm afraid nothing is that simple
I've seen logs where 'pressings' get mixed up in the database.
As far as i remember, and example of that would be when one person rips for example 2/3 tracks successfully.
He would see the following log after database submission and update:

track1: (1/1) Accurately ripped as in pressing(s) #1
track2: (1/1) Accurately ripped as in pressing(s) #1
track3: (0/0) No matches

Then second person rips the whole disc successfully from other pressing.
He would see the following log after database submission and update:

track1: (1/2) Accurately ripped as in pressing(s) #2
track2: (1/2) Accurately ripped as in pressing(s) #2
track3: (1/1) Accurately ripped as in pressing(s) #1
Offsetted by xxx:
track1: (1/2) Accurately ripped as in pressing(s) #1
track2: (1/2) Accurately ripped as in pressing(s) #1
track3: (0/1) No matches
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #317 –
Hell, where is the logic of having the track 3 of the second ripper/second pressing  falling on pressing #1 of the first ripper ? the first ripper didn't even ripped this track !!!  Or did the number # of the pressing switched after the second submission maybe ??? This is an accuraterip design flaw ... I hope accuraterip 2 will fix this, I think I will stop using accurate rip as long as such bugs happens. I don't want to get crazy trying to understand this kind of things.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #318 –
Something that I still don't understand is why this problem (the one in my log) would prevent us from doing a "total match no matter the offset" summary. Because if this is just a drive lag that adds samples of silence. It doesn't really matter, this rip is still accurate, no ? I mean there must be a way to remove these samples of silence in order to fix this lag , no ?

Your problem with pressings getting messed is the same, the targetted pressing may not be accurate, but the track 3 itself is accurate, no ?

As far as I understand, there are two different problems in the end, first drives that introduced lags/silence samples, secondly the accuraterip database being unable to recognise a target pressing.

The second can be fixed by accuraterip V2.0 I think, but the first can only be fixed by shifting data in order to match a single offset instead of two (always the first one), it should be Cuetools's job, no ?

Also, if the added samples were really duplicated data instead of just silence, the CRC wouldn't match no ? If the CRC of the track match somewhere & the offset doesn't match at the same time, as far as I understund, it means it is added silence & not added data ... So if this is just an added silence issue that should be fixable, no ?

I may be stupid but there is something I still don't get, sorry

for example with this log:

Code: [Select]
[Verification date: 26/03/2009 20:41:43]
[Disc ID: 00250406-016d08c7-d310dc0d]
Track	[ CRC	] Status
 01	[65103804] (00/44) No matches
 02	[880c6989] (00/49) No matches
 03	[afcc26e3] (00/45) No matches
 04	[ad5fffd6] (00/48) No matches
 05	[10a8aca8] (00/49) No matches
 06	[a61587d6] (00/49) No matches
 07	[a03ed93c] (00/49) No matches
 08	[25672619] (00/49) No matches
 09	[baff8a8d] (00/49) No matches
 10	[2565f4ee] (00/47) No matches
 11	[1a1da74c] (00/48) No matches
 12	[e8b25d28] (00/48) No matches
 13	[ec6a723b] (00/48) No matches
Offsetted by 48:
 01	[36898ee4] (11/44) Accurately ripped as in pressing(s) #3
 02	[10d48045] (12/49) Accurately ripped as in pressing(s) #3
 03	[4fcdbb54] (12/45) Accurately ripped as in pressing(s) #3
 04	[3c3946c8] (12/48) Accurately ripped as in pressing(s) #3
 05	[d00ef31a] (12/49) Accurately ripped as in pressing(s) #3
 06	[c36b43e6] (12/49) Accurately ripped as in pressing(s) #3
 07	[00d0ebec] (12/49) Accurately ripped as in pressing(s) #3
 08	[8318222a] (12/49) Accurately ripped as in pressing(s) #3
 09	[83082eb2] (12/49) Accurately ripped as in pressing(s) #3
 10	[9beb4a9a] (12/47) Accurately ripped as in pressing(s) #3
 11	[4d6928ed] (12/48) Accurately ripped as in pressing(s) #3
 12	[21d1f030] (12/48) Accurately ripped as in pressing(s) #3
 13	[1bcf0eab] (12/48) Accurately ripped as in pressing(s) #4
Offsetted by 898:
 01	[ed33781e] (04/44) Accurately ripped as in pressing(s) #4
 02	[85e7f147] (03/49) Accurately ripped as in pressing(s) #4
 03	[0918d581] (03/45) Accurately ripped as in pressing(s) #4
 04	[be7f65c6] (03/48) Accurately ripped as in pressing(s) #4
 05	[6ba5f8fa] (04/49) Accurately ripped as in pressing(s) #4
 06	[efa50f42] (04/49) Accurately ripped as in pressing(s) #4
 07	[b679c1a0] (04/49) Accurately ripped as in pressing(s) #4
 08	[d4ec5c97] (04/49) Accurately ripped as in pressing(s) #4
 09	[aa2c753c] (04/49) Accurately ripped as in pressing(s) #4
 10	[f2b9a2c6] (04/47) Accurately ripped as in pressing(s) #4
 11	[0fdf3889] (04/48) Accurately ripped as in pressing(s) #4
 12	[14f09bf2] (04/48) Accurately ripped as in pressing(s) #4
 13	[4dba0b95] (04/48) Accurately ripped as in pressing(s) #5
Offsetted by 1768:
 01	[823804ea] (23/44) Accurately ripped as in pressing(s) #1
 02	[d3b9f80e] (27/49) Partial match to pressing(s) #1 
 03	[ef3fd34e] (24/45) Accurately ripped as in pressing(s) #1
 04	[4993dad6] (26/48) Accurately ripped as in pressing(s) #1
 05	[7e8f4033] (26/49) Accurately ripped as in pressing(s) #1
 06	[157f2020] (26/49) Accurately ripped as in pressing(s) #1
 07	[69ab88a6] (26/49) Accurately ripped as in pressing(s) #1
 08	[96183220] (26/49) Accurately ripped as in pressing(s) #1
 09	[f2eb2ec8] (26/49) Accurately ripped as in pressing(s) #1
 10	[8cd9bc31] (24/47) Accurately ripped as in pressing(s) #1
 11	[cad6ee29] (25/48) Accurately ripped as in pressing(s) #1
 12	[8df2a7f5] (25/48) Accurately ripped as in pressing(s) #1
 13	[68b99f03] (25/48) Partial match to pressing(s) #1,3 

Track	[ CRC32  ]	[W/O NULL]	
 --	[65D55916]	[35665AD9]	
 01	[A9636AF3]	[7C5C5FA0]	
 02	[F0B6C557]	[E3E7D8D7]	
 03	[7C431AE8]	[31D8D380]	
 04	[9FBA64A1]	[76BCAFE3]	
 05	[A05D79E0]	[A06A4909]	
 06	[E70669BD]	[0EA9994B]	
 07	[F850D617]	[34BDFFE2]	
 08	[7A91883F]	[A4D7DC4F]	
 09	[0A2AC3C3]	[4DA10F98]	
 10	[70FA3A12]	[55268F82]	
 11	[526790AB]	[F8C96214]	
 12	[40894DFD]	[28DBE38F]	
 13	[51A87217]	[78DD6AB1]

If you offset track 13 alone by 48 & all the other tracks by 898, you should be able to end with a perfect pressing #4 ? no ? maybe I missed something & I am completly wrong, it's already not easy to understand when you are a native english, so when you are a foreigner I get headaches. Much sorry if I ask stupid questions ...
Something must be wrong with my way of thinking because if I were right track 13 from pressing #4 should have the same confidence as the other track of pressing #4 (3 or 4) but it doesn't as it have the same confidence as tracks from pressing #3 (11 or 12), something is not logic but I don't get what it is ... I know I must be wrong somewhere.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #319 –
I was just saying that pressing based (instead of offset based) representation, like you suggested, might be misleading. In my example it would look like that:

track1: (1/2) Accurately ripped as in pressing(s) #2
track2: (1/2) Accurately ripped as in pressing(s) #2
track3: (0/1) No matches
Offsetted by xxx:
track1: (1/2) Accurately ripped as in pressing(s) #1
track2: (1/2) Accurately ripped as in pressing(s) #1
track3: (1/1) Accurately ripped as in pressing(s) #1 offsetted by -xxx Warning offset mismatch

When in fact the rip is absolutely accurate.

As for your example, i don't quite understand what happens there too.
But i don't think you have extra samples, i think you have lost 36 samples.
And i think it happened somewhere on the border of tracks 12 and 13, but hard to say where exactly.
One offset says they are in track 12, other offset says they are in track 13.
The difference between them is 96 samples.
So assume those lost 36 samples are somewhere within those 96 samples.
That leaves 60 possible locations for them.
Interesting mathematical problem, but if i were you i wouldn't waste time on it.
I would just consider any rip where i cannot immediately interpret the log as "most probably inaccurate".
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #320 –
> with no offset lag warning because there wouldn't be any offset difference within the same pressing in this case.
Nope.
You are forgetting that the third track in my example will only have a database entry in pressing #1, not #2.
Anyway, let's not depress new users too much with all those boring logs
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #322 –
Quote from: Gregory S. Chudov on
Quote from: Scidd0w on
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?
Are there any objections to make it a part of 'create cue' action? Right now it creates dummy cue sheets for file-per-track images, but what if it would also extract embedded cue sheets?
This would be perfect for me! Thank you in advance.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #323 –
I have a cosmetic request, could you add a zero in front of number count when 100 is reached, in order that every result line get aligned on the right ? (maybe the new experimental version already does that, I didn't check)

04 [f7f61bc0] (61/225) Accurately ripped as in pressing(s) #2
05 [ec15c042] (160/226) Accurately ripped as in pressing(s) #2

01 [b583cf45] (14/99) Accurately ripped as in pressing(s) #6
02 [eca3e197] (15/100) Accurately ripped as in pressing(s) #6

04 [f7f61bc0] (061/225) Accurately ripped as in pressing(s) #2
05 [ec15c042] (160/226) Accurately ripped as in pressing(s) #2

01 [b583cf45] (14/099) Accurately ripped as in pressing(s) #6
02 [eca3e197] (15/100) Accurately ripped as in pressing(s) #6

Well it isn't aligned on my exemple but it should be in the log. I'm sure you get what I mean, you already do it for number from 1 to 9.

Edit:
Plz Gregory, remove the pressing #number, this information is worthless & caused me much trouble, only the offset matters.
See splitted discussion The pressing #number is useless, Thks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #324 –
Quote
Quote
(Tigerman @ Mar 29 2009, 13:47) *
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.


(Gregory S. Chudov post Apr 1 2009, 01:13)

For now, i would sugest dropping it to a file tree instead of input text box.


Thanks for the tip, works great.
Would be nice if refresh (F5) worked in the tree.

Also thanks for the tip for locating missing audiofiles.