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 1895531 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #475
Compare the 2 logs.

1) Why is the "Accurately ripped with offset(s) 0(2)" in the non-verbose log? I thought that "Partial match to pressing(s)" meant that track is NOT accurately ripped.

1.1) Is the "Partial match" really necessary? Especially if that really means that the rip was NOT good at all.

2) Why is there two "280(2)" listed?

3) Why is there one "1690(2)" and one "1690(0)" listed?

4) If it's true that "if all tracks within one offset are accurately ripped, the DISC is accurately ripped", then shouldn't the non-verbose log show only the confidence numbers from "whole offset(s) fully accurately ripped"? (example below)

 01    (07/09) Accurately ripped with offset(s) 12(5),1690(2)
 02    (07/09) Accurately ripped with offset(s) 12(5),1690(2)
 ...

IMHO the current non-verbose output, simply put, lies about the accurate statuses e.g. in this case. Or if not lies, then at least it represents the situation very difficultly.. in the end the "09/09" for that 1st track is NOT "correct".. that's the easiest figure/result to understand, IMHO the offsets stuff is too hard to decipher to normal users. The AR stuff is hard enough to understand already, please try to make it more easier to understand. Thanks.

Code: [Select]
[Disc ID: 001165eb-009914a6-9b0b400b]
Track [ CRC    ] Status
 01 [733a3c74] (02/09) [color=#FF0000]Partial match to pressing(s) #2[/color]
 02 [647133aa] (02/09) Accurately ripped as in pressing(s) #2
 03 [5ea8c8cb] (02/09) Accurately ripped as in pressing(s) #2
 04 [200fe976] (02/09) Accurately ripped as in pressing(s) #2
 05 [7fcc75a0] (02/09) Accurately ripped as in pressing(s) #2
 06 [174b2628] (02/09) Accurately ripped as in pressing(s) #2
 07 [a61e417e] (02/09) Accurately ripped as in pressing(s) #2
 08 [89e54391] (02/09) Accurately ripped as in pressing(s) #2
 09 [125ec64e] (02/09) Accurately ripped as in pressing(s) #2
 10 [cde305a7] (02/09) Accurately ripped as in pressing(s) #2
 11 [cd3692ce] (02/09) Accurately ripped as in pressing(s) #2
Offsetted by 12:
 01 [f810eac3] (05/09) Accurately ripped as in pressing(s) #1
 02 [674e80df] (05/09) Accurately ripped as in pressing(s) #1
 03 [8b0e7c4e] (05/09) Accurately ripped as in pressing(s) #1
 04 [f6c64064] (05/09) Accurately ripped as in pressing(s) #1
 05 [3107a254] (05/09) Accurately ripped as in pressing(s) #1
 06 [c528d657] (05/09) Accurately ripped as in pressing(s) #1
 07 [62383801] (05/09) Accurately ripped as in pressing(s) #1
 08 [3ca8f35d] (05/09) Accurately ripped as in pressing(s) #1
 09 [a220407f] (05/09) Accurately ripped as in pressing(s) #1
 10 [812c1092] (05/09) Accurately ripped as in pressing(s) #1
 11 [e042a7c7] (05/09) Accurately ripped as in pressing(s) #1
Offsetted by 280:
 01 [51d2c1b1] (02/09) Accurately ripped as in pressing(s) #2
 02 [4b880d8d] (00/09) No matches
 03 [1aed0e9e] (00/09) No matches
 04 [0c6900e4] (00/09) No matches
 05 [47478718] (00/09) No matches
 06 [4f1b6237] (00/09) No matches
 07 [b5c87777] (00/09) No matches
 08 [77c22e05] (00/09) No matches
 09 [c1a449cd] (00/09) No matches
 10 [26001712] (00/09) No matches
 11 [0607bd12] (00/09) No matches
Offsetted by 1690:
 01 [0cdfc996] (02/09) Accurately ripped as in pressing(s) #3
 02 [3c459d7e] (02/09) Accurately ripped as in pressing(s) #3
 03 [f8e0ac37] (02/09) Accurately ripped as in pressing(s) #3
 04 [687a061c] (02/09) Accurately ripped as in pressing(s) #3
 05 [502eee2f] (02/09) Accurately ripped as in pressing(s) #3
 06 [f5164085] (02/09) Accurately ripped as in pressing(s) #3
 07 [a1400942] (02/09) Accurately ripped as in pressing(s) #3
 08 [3abf62fe] (02/09) Accurately ripped as in pressing(s) #3
 09 [5fd526a3] (02/09) Accurately ripped as in pressing(s) #3
 10 [3b920429] (02/09) Accurately ripped as in pressing(s) #3
 11 [7f674c04] (02/09) Accurately ripped as in pressing(s) #3

Code: [Select]
[Disc ID: 001165eb-009914a6-9b0b400b]
Track Status
 01 (09/09) Accurately ripped with offset(s) [color=#FF0000]0(2)[/color],12(5),[color=#FF0000]280(2),280(2)[/color],[color=#FF0000]1690(2),1690(0)[/color]
 02 (09/09) Accurately ripped
 03 (09/09) Accurately ripped
 04 (09/09) Accurately ripped
 05 (09/09) Accurately ripped
 06 (09/09) Accurately ripped
 07 (09/09) Accurately ripped
 08 (09/09) Accurately ripped
 09 (09/09) Accurately ripped
 10 (09/09) Accurately ripped
 11 (09/09) Accurately ripped

This is the last part of my questions/etc.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #476
Hi Gregory,

I'm testing 2.0.3a.

Two issues so far:

1) the new compression level control doesn't remember the last setting used. This is a step back for me, as I always encode FLACs at 8, en everytime I restart the CUETools it starts with the default 5 compression level.

2) Can you add the option in Audio output formatting "Use CUE formatting template" ?  Since I deal with single FLACs & CUEs, both with the same name, whenever I need to switch the CUE template, I need to manually change the Audio formatting config.

3) Not an issue really, but what about my previous request for writing the ACCURATERIPID tag for Single File + CUE ?

Thanks,

N.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #477
I'm sorry but what purpose does the "as in pressing(s) #x" information serve? Is it in any way usable?

Even Spoon agrees that this information is useless.  It should be removed.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #478
Tried Cuetools 2.0.3.a in drag 'n dropmode.
While verifying it shows if an album is accurately ripped just as in 2.02. After finishing it shows in the batch log but in that just the directories which were dropped.
It shows the status report after switching to drag'n drop mode (or (multiselect) file browser) and then to batch log again.

Also the switching to batch-log is imho no improvement to the status report in separate window. Instead of a close button, the drag'n drop icon must be clicked before continuing.
I would very much like a separate window or area in which the status report is shown which doesn't intervene with dragging and dropping.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #479
Tried Cuetools 2.0.3.a in drag 'n dropmode.
While verifying it shows if an album is accurately ripped just as in 2.02. After finishing it shows in the batch log but in that just the directories which were dropped.
It shows the status report after switching to drag'n drop mode (or (multiselect) file browser) and then to batch log again.


I forgot to mention this happens with dragging more than 1 directory

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #480
I still use v2.02a because of the display bug with 125% font which has get worst in 2.03


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #481
I still use v2.02a because of the display bug with 125% font which has get worst in 2.03


Are you talking about version from [a href='index.php?act=findpost&pid=643682']this[/a] post?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #482
No, I was speaking of the one in the download front page. Thks for the fixed version I missed it. I didn't test it much so far, but the display seems to work ok now. It's a good news that it is finally fixed as it has been annoying me for months now.

V2.03 with Fixed Display: (on Windows 7 RC1)


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #483
Can you please compare your files length with the log? Foobar2000 can show you the file's length in samples. The length from log is calculated like this: (End sector + 1 - Start sector) * 588.
e.g. the first track should have length (34486+1-600)*588==19925556 samples.

My current hypothesis is that EAC made some tracks shorter, when it failed to rip them.

All tracks had the correct length, but I think the data-track is the culprit here - I don't have an audio-file the the data-track. I tried entering 0:08:00 in the "Data track" inputbox, but still fails.
Can't wait for a HD-AAC encoder :P

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #484
I just post to say that the bug with 125% fonts is only partially fixed, in fact the part that was fixed is the buggy main windows introduced in v2.03, the buggy advanced settings/accuraterip windows from 2.02a remains buggy:

Still buggy advanced settings in v2.03 "fixed" version: (look on the right)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #485
Don't know if it is by design,but (on inactive window) if I want to click on a button (p.e. for drag'n'drop mode) then I need to click twice (using 2.0.3a).
One click to activate window, second one for the button.
On all other programs I use, this is done with only one click (I mean activating window and performing the function of the button I click)


P.S. please make a small drag'n' dropzone above the batch log zone. It happens so many times that I want drop something and discover that the program is in batch log mode.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #486
I'm afraid that's how .NET framework toolbars work, not sure if i can fix it.

As for the batch log, in the next version it will not overlap with drag'n'drop zone/browser. It will be below the main window.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #487
Hi Gregory, maybe you've been busy or something, or you just missed my 2 posts (#475 and #476) from last weekend, if that's the case, can you check them? When you have time of course. Thanks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #488
I usually answer complex questions when i'm working on a new version, after i've tested it and tried out different ways to fix/change the described/desired program behavior and see how it works. A new version is usually the best answer.

> Or can I only be confident [that my pressing of the CD is ok] when all tracks WITHIN one offset are accurately ripped?
Well yes, but it is almost mathematicly impossible to have all tracks accurately ripped with different offsets, and not have a single offset which fits all tracks.
Let's say track 1 fits offset 555 and track 3 fits offset 666. That means 111 samples were lost somewhere on track 2.
Track 2 will be inaccurate, unless it consists entirely of digital silence.

Being paranoid is part of programmer's job description, so i guess i'll add a check for such cases sooner or later, but from a practical viewpoint i would not worry too much about this.

P.S.: I'm looking at the logs, will reply to that a bit later.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #489
> Why is the "Accurately ripped with offset(s) 0(2)" in the non-verbose log? I thought that "Partial match to pressing(s)" meant that track is NOT accurately ripped.

Current algorithm for nonverbose log is simple:
1) it treats each track separately
2) for each track it answers two different questions separately:
  a) was the track ripped correctly, and with what confidence?
  b) what were the offsets?

The first track was indeed ripped correctly with confidence 9: there were 5 rips matching with offset 12, 2 rips matching with offset 280 and 2 rips matching with offset 1690.
As for offsets, there are 3 entries in the database, each holds 2 CRCs, thus producing 6 possible offset matches (3 possible partial matches and 3 possible complete matches).
Of course each offset should be reported only once. And this would be the case if partial CRCs and complete CRCs were linked in the database, but sometimes they are not, as in this case.
That's why this wierdness showed up. This also made me realize that offsets that lead to partial matches should be listed separately.
Thanks, i'll fix it.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #490
Hi,
Thanks a lot for a great program!

Got a small feature request:
Add support for lowercase filenames in the renaming section.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #491
I only post to say that I just downgraded from 2.0.3a to 2.0.2a, I don't like the new way of displaying log (the window is too small), I don't like the fact that 2.03a don't recall my flac setting & I don't like that that 2.03a doesn't recall that I always use drag&drop mode. I don't like the fact that I must now set up the default saving folder instead of just using "same folder+append to filename". Overall 2.03 was a painfull experience for me. Lots of useless clicks & wasted time compared to 2.02 which I am happier with.

Not everything is bad, I like "* Compression level selected in the main window" for exemple, but 2.03 is a very little gain for a huge pain from my point of view. Sorry ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #492
That's what experimental versions are for - to find out what works best.
All those problems will be addressed in the next version,
and probably some new problems added

By the way, "same folder+append to filename" works ok in 2.0.3a,
you just have to select the appropriate template from the drop down list:
[%directoryname%\]%filename%-new[%unique%].cue
CUETools 2.1.6


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #494
Whether there will be a version for linux?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #495
Very likely. Some people already run command-line tools like ArcueDotNet using mono.
This only works with WAV's, but now that CUETools supports external encoders/decoders, flac support can be easily added.
I'm also starting to test UI version with mono. It's not pretty, but it works.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #496
I usually answer complex questions when i'm working on a new version, after i've tested it and tried out different ways to fix/change the described/desired program behavior and see how it works. A new version is usually the best answer.

Ok good to know, different approach than devs usually have.. sorry if I pressured.

As for the rest of the stuff concerning AR and your logs, I'm afraid that I've no more time and sadly I'm getting more confused. I've a hard time understanding your answers completely. I think that you're looking at the thing from a technical perspective and I look at it differently. Isn't the whole AR thing meant to be used as verifying whole albums (though technically it checks the tracks separately), not just individual tracks? Maybe here's the problem, people want to verify their albums as a whole, and then your logs looks/presents the results as only thinking of individual tracks (non-verbose log, though the offsets are mentioned but those IMHO are too hard to understand for a "non-propeller hat" user). I dunno, I could be way off.. I'm too confused with this. Thanks for the answers though and your work, I still hope that you could make the logs more understandable (*wink wink* at least remove the "as in pressing(s)" texts).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #497
(I apologize if this is duplicating anything that's already been mentioned in previous posts.  There were just too many to go through at the time.)

Would you please consider sorting the subdirectory list in the file browser pane in a future release?  On FAT32 partitions, subdirectories appear in the order in which they "physically" exist in the directory.  This often leads to non-alphabetized subdirectory lists in the browser pane, making a specific one hard(er) to find.  This isn't an issue on NTFS partitions, of course, just FAT32 partitions.  Yes, a few of us dinosaurs still exist. 

Thanks for at least considering this minor request and thanks to you and Moitah for all your great work up to now.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #498
I'm wondering if I'm missing something- is there a way, in 2.0.3 in the file browser, to have the directories appear in alphabetical order?  The multiselect directories is fabulous, but actually finding the directories is a pain because they're all mixed up.  What order are they in?  There was a post about sorting subdirectory lists on FAT32 partitions, but mine are NTFS and they do not appear sorted either.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #499
Thanks for adding the drag'n'drop zone in next version  .

I found another bug (at least I think it is a bug and not by design) in 2.0.2a and 2.0.3a: When selecting Drag'n'drop mode, the Freedb lookup is disabled (greyed out) and no lookup is done.

Also in multiselect mode the freedb lookup is disabled.