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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1450
I put together the tracks from a log posted by Sauvage78 (track 01 & 02) and a case example posted by Gregory (track 03).
I should have mentioned it...

On a side note, I'm not sure what happens with ARv2 information and alternate offsets. I may take a look at more ARv2 logs once I get my computer back.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1452
I have feature request, please preserve existing replaygain information after conversion

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1453
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request  please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1454
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request  please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).


That's right for ->loosy, but I talked about lossless->losless where no clipping or normalization is applied
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1455
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.

Would be great, and there are different 'kinds' of RG so far (vanilla vs. EBU R128) thus a config option would be welcome.


Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1456
Thanks, Gregory!

Seems that "Verify only if found" doesn't take in account present CTDB-entry even if "Use CTDB" checked. I suppose it should.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1457
I'm still accustoming to the new log, so I know for sure you will wisely spare. 

Is this rip accurate or not?
Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: gVxhEOQHHEPNFvQ9qjE12ZbNjmU-] found.
        [ CTDBID ] Status
        [085e4f05] (2/2) Accurately ripped
[AccurateRip ID: 000a1243-003624b0-3c0a3c06] found.
Track  [ CRC    ] Status
 01    [d0c6fdd1] (0/2) No match but offset
 02    [5793ed0e] (0/2) No match but offset
 03    [8621b7af] (0/2) No match but offset
 04    [506332c0] (0/2) No match but offset
 05    [b5862057] (0/2) No match but offset
 06    [bd42b7cc] (0/2) No match but offset
AccurateRip v2:
 01    [057f19b3] (2/2) Accurately ripped
 02    [442fd49a] (2/2) Accurately ripped
 03    [14e4a138] (2/2) Accurately ripped
 04    [f0486f43] (2/2) Accurately ripped
 05    [05bcb5a6] (2/2) Accurately ripped
 06    [76cec823] (2/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [2944617A] [5D2AC446]  CRC32 
 01  100,0 [BA67ECCA] [BB1C7900]         
 02  100,0 [B721AA8D] [4E492126]         
 03  100,0 [F7562C3A] [B60E0DED]         
 04  100,0 [24376FAD] [C3AC539F]         
 05  99,5 [C95E7F53] [0D31B664]         
 06  99,2 [9AD39544] [276F7423]         
I guess no. Do you?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1458
I'm still accustoming to the new log, so I know for sure you will wisely spare. 

Is this rip accurate or not?

I guess no. Do you?

I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read [a href=\'index.php?act=findpost&pid=759329\']this[/a] and [a href=\'index.php?act=findpost&pid=759959\']this[/a].

Does it really look that different?

Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped

korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1459
It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1460
Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

I don't know CUEtools, but i think this should be easy to implement. Does it take more than storing the data as APEv2 tags, which is the standard for TAK?

Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)

Unfortunately TAKC currently does not have an option to extract only a part of a compressed file. Sorry... I will put it on my to do list.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1461
I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read [a href=\'index.php?act=findpost&pid=759329\']this[/a] and [a href=\'index.php?act=findpost&pid=759959\']this[/a].

Does it really look that different?

Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped
As sauvage stated some pages back: 'what I don't really understand is why AR V2 reports "No match but offset" instead of simply "No match"'. That "No match but offset" sounds like a bad rip to me too. 


It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. 
Here's the EAC log for that rip.

Code: [Select]
AccurateRip summary
 
Track  1  cannot be verified as accurate (confidence 2)  [D0C6FDD1], AccurateRip returned [057F19B3]
Track  2  cannot be verified as accurate (confidence 2)  [5793ED0E], AccurateRip returned [442FD49A]
Track  3  cannot be verified as accurate (confidence 2)  [8621B7AF], AccurateRip returned [14E4A138]
Track  4  cannot be verified as accurate (confidence 2)  [506332C0], AccurateRip returned [F0486F43]
Track  5  cannot be verified as accurate (confidence 2)  [B5862057], AccurateRip returned [05BCB5A6]
Track  6  cannot be verified as accurate (confidence 2)  [BD42B7CC], AccurateRip returned [76CEC823]
 
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report
Regards!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1462
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. 
Here's the EAC log for that rip.

Code: [Select]
AccurateRip summary
 
Track  1  cannot be verified as accurate (confidence 2)  [D0C6FDD1], AccurateRip returned [057F19B3]
Track  2  cannot be verified as accurate (confidence 2)  [5793ED0E], AccurateRip returned [442FD49A]
Track  3  cannot be verified as accurate (confidence 2)  [8621B7AF], AccurateRip returned [14E4A138]
Track  4  cannot be verified as accurate (confidence 2)  [506332C0], AccurateRip returned [F0486F43]
Track  5  cannot be verified as accurate (confidence 2)  [B5862057], AccurateRip returned [05BCB5A6]
Track  6  cannot be verified as accurate (confidence 2)  [BD42B7CC], AccurateRip returned [76CEC823]
 
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report
Regards!

 EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2.  CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1463
It would be great if the 'Correct filenames'-action would create UTF8-encoded CUEs when necessary. At the moment, it substitutes every non-ANSI character with a ?. Therefore, I'm using the 'Encode'-action without audio output and without using any databases to fix the filenames, as that creates unicode CUEs if needed.
However, that doesn't always work as expected though: I thought, when turning off all checkboxes in the 'Tagging'-settings, it would keep everything besides filenames and structure as it is. But for some CUEs/discs, it just removes some REM or CD-TEXT lines. Sometimes it even adds empty CD-TEXT lines (like PERFORMER "") when there were none before. So I need to check the fixed cue against the original manually everytime I do that.
An option to allow/prevent CUETools from creating such CUEs might be a good idea, I bet there are people who don't want it.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1464
I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

1 question:
What exactly does fix offset script with encode. I have verified on rip with shifted offset. As best match was results with +6 offset. If chosing Encode+fix offset, the progress failed. If chosen Encode+normal and manually giving offset +6, the progress succeed and offset was fixed. Then what's 'fix offset' good if it can't find correct offset value and apply for reencode. If the offset is obvious from verify results set.

What about the RG rescan? It's not as hard to do by another tool but I forget often to do that. At least preserve existing tags.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1465
To Anakunda:
I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

It’s Not A Bug, It’s A Feature!
"Verify" also writes AR tags in source file on success, but currently only flac album image (with embedded cue) is supported for this.


To Gregory:
Now CUETools after encode, change multivalue tags (album, genre, artist, title) in comma separate one-value form. Example, i have multivalue genre "Jazz-Funk;Soul" after encode genre is one-value "Jazz-Funk, Soul". Please add options to copy this multivalue tags as is, whitout any change.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1466
EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2.  CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.
Oops!  Sometimes I completely forget about this new feature.
This is my very first rip with ARv2 support. Hope to be spared! 
Thanks for your ready guide, korth!
By the way, here's the new log...
Code: [Select]
Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 2. July 2011, 21:10

Jakszyk, Fripp & Collins / A Scarcity of Miracles

Used drive  : HL-DT-STDVD-ROM GDR-H30N  Adapter: 0  ID: 1

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

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

Used output format              : User Defined Encoder
Selected bitrate                : 128 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : C:\Archivos de programa\Exact Audio Copy [v1.0b1]\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%albumtitle%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "COMMENT=EAC (Secure Mode)" %source% -o %dest%


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  7:26.67 |        0    |    33516 
        2  |  7:26.67 |  4:47.13 |    33517    |    55054 
        3  | 12:14.05 |  7:47.51 |    55055    |    90130 
        4  | 20:01.56 |  8:37.14 |    90131    |  128919 
        5  | 28:38.70 |  5:59.27 |    128920    |  155871 
        6  | 34:38.22 |  9:02.18 |    155872    |  196539 


Range status and errors

Selected range

    Filename D:\Lossless\Jakszyk, Fripp & Collins - A Scarcity of Miracles\Jakszyk, Fripp & Collins - A Scarcity of Miracles.wav

    Peak level 100.0 %
    Extraction speed 6.2 X
    Range quality 100.0 %
    Copy CRC 2944617A
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 2)  [057F19B3]  (AR v2)
Track  2  accurately ripped (confidence 2)  [442FD49A]  (AR v2)
Track  3  accurately ripped (confidence 2)  [14E4A138]  (AR v2)
Track  4  accurately ripped (confidence 2)  [F0486F43]  (AR v2)
Track  5  accurately ripped (confidence 2)  [05BCB5A6]  (AR v2)
Track  6  accurately ripped (confidence 2)  [76CEC823]  (AR v2)
 
All tracks accurately ripped

End of status report

==== Log checksum 4821C1E0A71ED22BCC5575B6E56F7FC9E954073131B8FB700CAECD62A25988AF ====
Just nice!
Regards!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1467
Gregory, thank you very much for 2.1.2a

Any chance of writing the ACCURATERIP tags to ALAC ? Cheers

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1468
Hello, I have been using a way old CueTools version, and have just upgraded to the 2.1.2 version, which I am pleasantly surprised at evolution of new features :-)  Also appreciating mirroring the syntax used in foobar.

Is it possible to use CueTools to convert a FLAC image and Cue to tracks with revised Cue, and preserve the custom tags?  I see a setting in Advanced>Tagging "Copy unknown tags" which I thought would do this, but it is only copying standard tags (artist, title, etc).  If it is possible would that also include ReplayGain? I'm guessing no from comments just above...

I know I can always use foobar to split to tracks and preserve the tags, and then batch convert the cues with CUE Tools, but would be great to do in one shot.  If this is already answered somewhere else in the thread please point my weary eyes there :-) Thank you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1469
Would it be possible to add an option for keeping the timestamps of a file when converting or correcting it?

Also, a question about error messages. Like here in that accurip
Quote
[CTDB TOCID: FodNAscYq_hxDOrxrgrUq6AcLBc-] database access error: Timeout für Vorgang überschritten.

and here from a EAC log (with the CTDB plugin, obviously)
Quote
[CTDB TOCID: rQdoeISrw6aMymKgoVQkFW5VbHk-] found, Submit result: database access error: Die Anfrage wurde abgebrochen: Die Anfrage wurde abgebrochen..

Why is a part of it in German? Is it because my OS locale is German? Both programs are set to English, in EAC even the 'always-english-log'-option is set. Can I do something about it?
And while we're at it, I think the submit results shouldn't be included in a EAC log, just the verify results. But that's just my opinion.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1470
Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1471
The latest CUERipper V2.1.2a doesn't write accurip tags to my flac files. Is this a known issue?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1472
Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you


The problem is found.

Source files are recoded to 48kHz. Why FLAC? 

It will be good if program can report something like this:
"The source files are not seems to be a CD audio.
Reason: Sample rate is 48kHz"

The suggestion is based on the WAVTools message

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1473
Using 2.1.2a, converting individual flac files to 1 file-per-album tta+cue, the tta files have apev2 tags. Shouldn't they be ID3 tags? Are apev2 tags now complient in tta files?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1474
"Exception: Error reading CD: NO SENSE STRING FOR ASC=02, ASCQ=00"

According to SCSI docs, this error reported by the drive means "NO SEEK COMPLETE", whatever that means. CUERipper can translate most of SCSI error messages to strings, but this one was forgotten. This will be fixed.
My guess is that this drive had unrecoverable problems reading a certain sector of this CD.
CUETools 2.1.6