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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2625
I said it puts two FLAGS PRE lines on each track. It's supposed to only write one per track.

Not my finest hour - many apologies 
I have several pre-emphasis CDs, but ripped them a while back with 2.1.4, which may be why I haven't come across the bug yet.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2626
Has it already been reported that FlacCL is showing a negative filesize when the encoded file is bigger than 2^31 bytes?

Code: [Select]
>CUETools.FLACCL.cmd.exe --verify file.wav
CUETools FLACCL 2.1.6, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : file.wav
File Info : 48000kHz; 6 channel; 16 bit; 02:05:22.2720000
Device    : GeForce GT 640, Platform: "NVIDIA CUDA", Version: OpenCL 1.1 CUDA 7.
0.23, Driver: 347.52
Results   : 74,15x; -2107532821 bytes in 00:01:41.4469782 seconds;

Size of encoded file: 2187434475 bytes.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2627
And this happens when the file is bigger than 4GB:
Code: [Select]
>CUETools.FLACCL.cmd.exe -5 --verify test.wav
CUETools FLACCL 2.1.6, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test.wav
File Info : 48000kHz; 6 channel; 16 bit; 04:08:33.0810000
Device    : GeForce GT 640, Platform: "NVIDIA CUDA", Version: OpenCL 1.1 CUDA 7.
0.23, Driver: 347.52
Results   : 58,62x; 140368563 bytes in 00:04:14.4052468 seconds;

Actual filesize is 4435335859 bytes (2^32+140368563 bytes).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2628
^^^ Could be a case of "garbage in, garbage out." A WAV greater than 4 GB is non-compliant.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2629
I'll concede the "non-compliant" point, but it might still be a good idea to future-proof the software if there does come a day when >4GB source PCM files are common.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2630
^^^ Could be a case of "garbage in, garbage out." A WAV greater than 4 GB is non-compliant.

It is? Didn't know that.
That would explain the error ("partial sample") I got when encoding the 4.0x GB big file with flac.exe. 
FlacCL was encoding it fine, though.

Thanks for your reply.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2631
That would explain the error ("partial sample") I got when encoding the 4.0x GB big file with flac.exe. 

flac has --ignore-chunk-sizes option for such files:
Quote
WAV and AIFF files both have an unsigned 32 bit numbers in the file header which specifes the length of audio data. Since this number is unsigned 32 bits, that limits the size of a valid file to being just over 4 Gigabytes. Files larger than this are mal-formed, but should be read correctly using this option.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2632
What about CUERipper? Is the latest version reliable, compared to EAC, for example? I tried to rip a CD and I noticed that, if a certain option is selected, it produces a log almost identical to the EAC one. I suppose that EAC and CUERipper share the same error detection/handling techniques/files? Anyway, I would suggest to add more editable fields, here is a screenshot of EAC:



I would suggest to add the fields marked in red, because they seem to be missing from CUERipper, whilst being useful.
Another cool thing to do, could be to add GD3 metadata retrieval. But I don't know if it's free.
These are only suggestions, what do you think? Thanks for your hard work!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2633
I have found the commandline tool ArCueDotNet.exe in the installation folder of CueTools and it works   

e.g.: -o65
uses the offset 65 (and calculates V2 for this offset)

o without offset declaration: -o
calculates the V2 value for all detected offsets (like running ArCueDotNet multiple times with -o<offset1>,  -o<offset2>, ...). This is usefull to see the best offset for a Rip without "Read offset correction".


I would find that to be useful for some of my albums. Moreover, would there be a way to add --verbose to "CUETools.exe /verify" mode? Here is the output of ArCueDotNet.exe with -v option:

Code: [Select]
[CUETools log; Date: 28/02/2015 04:42:21; Version: 2.1.5]
[CTDB TOCID: LAKiIVhc1gSqZ8BE.7VGBxXwMaE-] found.
        [ CTDBID ] Status
        [5c7170fc] (19/21) Accurately ripped
        [bb2246f5] (01/21) No match
        [5db9fe31] (01/21) No match
Track | CTDB Status
  1   | (19/21) Accurately ripped
  2   | (20/21) Accurately ripped
  3   | (20/21) Accurately ripped
  4   | (20/21) Accurately ripped
  5   | (20/21) Accurately ripped
  6   | (20/21) Accurately ripped
  7   | (20/21) Accurately ripped
  8   | (20/21) Accurately ripped
  9   | (20/21) Accurately ripped
10   | (20/21) Accurately ripped
11   | (20/21) Accurately ripped
12   | (20/21) Accurately ripped
[AccurateRip ID: 0019e705-00f3b536-9e0e480c] found.
Track   [  CRC   |   V2   ] Status
01     [54d5b239|8c859a29] (07+12/22) Accurately ripped
02     [9abaa277|446f813f] (07+13/23) Accurately ripped
03     [e671a3ee|df8aefac] (07+12/22) Accurately ripped
04     [131645c5|08404059] (07+13/23) Accurately ripped
05     [fa677611|1fcf6226] (07+12/21) Accurately ripped
06     [a48fb312|abf5ba0c] (07+13/22) Accurately ripped
07     [482b2273|1371a315] (07+12/22) Accurately ripped
08     [061ecc0d|40eb99d7] (07+12/22) Accurately ripped
09     [a9a43e39|455299f8] (07+12/22) Accurately ripped
10     [c5d77042|4c99c432] (07+12/22) Accurately ripped
11     [5e115af1|060f38c5] (07+12/21) Accurately ripped
12     [9504d38d|fd07e8a8] (07+13/22) Accurately ripped
Offsetted by -664:
01     [cb3b9709] (03/22) Accurately ripped
02     [9df3c3be] (03/23) Accurately ripped
03     [19dbfde0] (03/22) Accurately ripped
04     [217183dd] (03/23) Accurately ripped
05     [34245dad] (02/21) Accurately ripped
06     [7ead2d66] (02/22) Accurately ripped
07     [e3a0ad42] (03/22) Accurately ripped
08     [38bcafa1] (03/22) Accurately ripped
09     [2c2d1bae] (03/22) Accurately ripped
10     [ffd9b6c1] (03/22) Accurately ripped
11     [3b71ecd8] (02/21) Accurately ripped
12     [efd1a32c] (02/22) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   99,9 [EF433381] [26CF379B]
01   98,9 [C27A1E39] [CEEB2201]   CRC32
02   93,4 [AB077A50] [FED0030F]   CRC32
03   93,4 [3A917A0E] [FD08F022]   CRC32
04   99,9 [9126A647] [9DD38039]   CRC32
05   99,9 [7CF0263A] [37888463]   CRC32
06   99,9 [9DFFF022] [BA5F9850]   CRC32
07   99,9 [DA170E31] [6C559762]   CRC32
08   99,9 [EA488401] [68C255C0]   CRC32
09   99,9 [846B12B2] [93950B27]   CRC32
10   89,1 [9B55BB04] [309042ED]   CRC32
11   99,9 [CBBEA6BA] [34C34B04]   CRC32
12   99,9 [B8A9843C] [D100069D]   CRC32


Here is the output of CUETools.exe with /verify option:

Code: [Select]
[CUETools log; Date: 28/02/2015 04:44:29; Version: 2.1.5]
[AccurateRip ID: 0019e705-00f3b536-9e0e480c] found.
Track   [  CRC   |   V2   ] Status
01     [54d5b239|8c859a29] (07+12/22) Accurately ripped
02     [9abaa277|446f813f] (07+13/23) Accurately ripped
03     [e671a3ee|df8aefac] (07+12/22) Accurately ripped
04     [131645c5|08404059] (07+13/23) Accurately ripped
05     [fa677611|1fcf6226] (07+12/21) Accurately ripped
06     [a48fb312|abf5ba0c] (07+13/22) Accurately ripped
07     [482b2273|1371a315] (07+12/22) Accurately ripped
08     [061ecc0d|40eb99d7] (07+12/22) Accurately ripped
09     [a9a43e39|455299f8] (07+12/22) Accurately ripped
10     [c5d77042|4c99c432] (07+12/22) Accurately ripped
11     [5e115af1|060f38c5] (07+12/21) Accurately ripped
12     [9504d38d|fd07e8a8] (07+13/22) Accurately ripped
Offsetted by -664:
01     [cb3b9709] (03/22) Accurately ripped
02     [9df3c3be] (03/23) Accurately ripped
03     [19dbfde0] (03/22) Accurately ripped
04     [217183dd] (03/23) Accurately ripped
05     [34245dad] (02/21) Accurately ripped
06     [7ead2d66] (02/22) Accurately ripped
07     [e3a0ad42] (03/22) Accurately ripped
08     [38bcafa1] (03/22) Accurately ripped
09     [2c2d1bae] (03/22) Accurately ripped
10     [ffd9b6c1] (03/22) Accurately ripped
11     [3b71ecd8] (02/21) Accurately ripped
12     [efd1a32c] (02/22) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   99,9 [EF433381] [26CF379B]          
01   98,9 [C27A1E39] [CEEB2201]   CRC32  
02   93,4 [AB077A50] [FED0030F]   CRC32  
03   93,4 [3A917A0E] [FD08F022]   CRC32  
04   99,9 [9126A647] [9DD38039]   CRC32  
05   99,9 [7CF0263A] [37888463]   CRC32  
06   99,9 [9DFFF022] [BA5F9850]   CRC32  
07   99,9 [DA170E31] [6C559762]   CRC32  
08   99,9 [EA488401] [68C255C0]   CRC32  
09   99,9 [846B12B2] [93950B27]   CRC32  
10   89,1 [9B55BB04] [309042ED]   CRC32  
11   99,9 [CBBEA6BA] [34C34B04]   CRC32  
12   99,9 [B8A9843C] [D100069D]   CRC32  
----------------------------------------------------------


As you can see, this second mode misses many good CTDB infos. Anyway, it would be cool for stats to include an option to add the [ CRC32  ] [W/O NULL]  columns for each different pressing (calculated at different offsets). It could take longer to elaborate, but one could choose to deactivate the option.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2634
What about CUERipper? Is the latest version reliable, compared to EAC, for example?

Define reliable.  CUERipper is like EAC and other "secure" rippers in that it has a strategy for detecting possible read errors (via re-reads and/or C2 pointers), and re-reading in a cache-defeating manner, all in an attempt to produce consistent data. It is also like those other rippers in that it checks the AccurateRip and CUETools databases to see if your rip is a match for others in the database, even if you do an ordinary "burst" rip rather than use the secure/paranoid modes. So, I think the answer to your question is yes.

IMHO, the most reliable possible-error detection is the AccurateRip and CTDB checking, at least for commercial CDs that other people have ripped and submitted to those databases. Re-reading or using C2 pointers to catch possible errors is good, too, but ideally you want to work the drive as little as possible. For commercial CDs, you only need the burst mode of EAC or most other rippers, plus verification in AccurateRip/CTDB. But if you rip a lot of damaged/defective discs, or you don't care about wear & tear of the drive, or your drive just doesn't perform very well in burst mode, then the convenience features of CUERipper or dbPowerAmp start looking more appealing. Personally I do a lot of whole-disc rips and my drive is not the greatest, so I just use CUERipper's secure mode for every rip, and I'm very happy with its simplicity and the price is right (free).

Quote
I tried to rip a CD and I noticed that, if a certain option is selected, it produces a log almost identical to the EAC one. I suppose that EAC and CUERipper share the same error detection/handling techniques/files?

Pretty much. They are not exactly the same; every ripper has a different idea of how to go about it, and the level of control the user has over each part of the process.

One thing to beware of is that CUERipper's EAC-style log will say "Copy OK" on all tracks, even if there were suspicious sectors. This is a superficial problem in the log; it doesn't mean CUERipper missed errors. I don't recall why it happens, but a search of this forum will probably reveal the answer.

Quote
I would suggest to add the fields marked in red, because they seem to be missing from CUERipper, whilst being useful.

I'll just comment on the Gap column. Like EAC, CUERipper scans for gaps and other indexes when generating a cue sheet, which is where that info lives. Unlike in EAC, in CUERipper you don't have the option of doing this scan ahead of time to see the info in a Gap column, and you can't choose any options to control how the detection is done. In my experience, you don't need any of that in CUERipper; it just works.

Pre-scanning for gaps in EAC is only something to do for odd situations where:
  • you want to see the Gap column so you can decide whether you like the results you're getting with the gap detection settings you chose (there are drive and CD combos that produce bogus results with some methods, for reasons unknown)
  • you want to write gap info into the log because you're not generating a cue sheet
  • you want to fulfill the requirements of an illicit file-sharing site's log checker and EAC setup guide

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2635
(There may be other reasons to pre-scan for gaps in EAC, but they are for even more obscure situations, like helping you decide whether you want to rip a TAO-mode CD-R with gaps removed, or do an index-based rip of a CD which uses gaps as non-silent interludes.)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2636
Thanks for your detailed answer, anyway I still haven't understood which kind of errors CUETools is able to report. For example, I see that the following is reported:

Suspicious position X:XX:XX

What about this?:

Missing samples

Moreover, how does Test&Copy really works? Someone tried to rip a scratched CD with CUERipper and, whilst reporting suspicious positions, the Test CRC was the same of Copy CRC. How could be that possible? I thought that Test & Copy, meant read 1st time, calculate CRC, read 2nd time for copy, calculate CRC, shouldn't it be like that?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2637
See [a href='index.php?act=findpost&pid=793333']Post #1851[/a]
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2638
See [a href='index.php?act=findpost&pid=793333']Post #1851[/a]


Excellent explaination, so with CUERipper I suppose the way to go for the highest chance of accurate rip would be Paranoid mode with no Test&Copy. One last suggestion, I just tried to rip with that setting, but the log seems to be identical to the one produced by a Secure mode with no Test&Copy. So, there is absolutely no way to distinguish between the two configurations. Wouldn't it be better to report something like:

Code: [Select]
Read mode               : Paranoid

instead of:

Code: [Select]
Read mode               : Secure

when the Paranoid mode is activated? At least we'll know that rip has been done with 3 passes. It wouldn't make sense in my opinion to report an identical EAC log, if ripping method is different.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2639
Why is CUETools saying there are illegal characters in path for this utf-8 .cue?
Code: [Select]
PERFORMER "Hiroyuki Sawano"
TITLE "Attack on Titan Exhibition"
FILE "01 ətˈæk 0N tάɪtn <3Tv>.wav" WAVE
  TRACK 01 AUDIO
    TITLE "ətˈæk 0N tάɪtn <3Tv>"
    PERFORMER "Hiroyuki Sawano"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Call your name <MODv>"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:16:36
FILE "02 Call your name <MODv>.wav" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "independent奇sayKISS"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:26:15
FILE "03 independent奇sayKISS.wav" WAVE
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    TITLE "ətˈæk 0N tάɪtn <3Tv> (Instrumental)"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:38:61
FILE "04 ətˈæk 0N tάɪtn <3Tv> (Instrumental).wav" WAVE
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "Call your name <MODv> (Instrumental)"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:16:36
FILE "05 Call your name <MODv> (Instrumental).wav" WAVE
    INDEX 01 00:00:00
At the same time, it doesn't have any problems reading the same characters in the filenames if I select the files instead?
This is an actual CD btw, the artist has a weird naming sense.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2640
I can see illegal characters '<' and '>' in the 2nd and 5th songs.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2641
Same here. The 1st and 4th songs have the full-width characters U+FF1C "<" and U+FF1E ">"
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2642
They are not illegal - full width characters can be used in NTFS file names. As I said, selecting the corresponding the files that have the same supposedly illegal characters in their filenames work fine.

edit: looks like I misread, you're of course right, for some reason the second and fifth songs have the half-width < > in the .cue (but not on disk). So yes, illegal characters in path indeed.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2643
NTFS allows characters that are illegal in Windows APIs.

Ordinary < and > as found in the filenames of track 02 and track 05 are the problem here, not the fullwidth ones. You cannot use Windows APIs to access files with the regular < or > characters in the names under any circumstances, AFAIK.

Can you rename those files? Maybe from within Cygwin or a Linux VM. Ah, I see the problem is just in the .cue. Great!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2644
Would it be possible and making sense to have the option to skip re-verifying tracks for which no new data is available at the Accurip and CUETools databases? Cheers.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2645
Hello, today I decided to make a test. I splitted a single FLAC image + CUE using Medieval CUE Splitter. I know that it is a shit software and NO-ONE SHOULD BE USING IT (!!!) . Anyway, I only wanted to make a test.
Then I checked the splitted tracks with CUETools, and I received the following message:

Code: [Select]
Padded some input files to a frame boundary.


My question is: how could I fix the splitted tracks so that they will be verifiable again with CUETools? I've tried with Trader's Little Helper, but I'm not sure about which settings to use:



This is a report of the SBE errors:

Code: [Select]
(01) [Alan Menken & Howard Ashman] Fathoms Below.flac:  audio data is not cut on a sector boundary (sector misalignment = 1616 bytes).
(02) [Alan Menken & Howard Ashman] Main Titles.flac:  audio data is not cut on a sector boundary (sector misalignment = 1024 bytes).
(03) [Alan Menken & Howard Ashman] Fanfare.flac:  audio data is not cut on a sector boundary (sector misalignment = 432 bytes).
(04) [Alan Menken & Howard Ashman] Daughters Of Triton.flac:  audio data is not cut on a sector boundary (sector misalignment = 1440 bytes).
(05) [Alan Menken & Howard Ashman] Part Of Your World.flac:  audio data is not cut on a sector boundary (sector misalignment = 1904 bytes).
(06) [Alan Menken & Howard Ashman] Under The Sea.flac:  audio data is not cut on a sector boundary (sector misalignment = 2224 bytes).
(07) [Alan Menken & Howard Ashman] Part Of Your World (reprise).flac:  audio data is not cut on a sector boundary (sector misalignment = 2112 bytes).
(08) [Alan Menken & Howard Ashman] Poor Unfortunate Souls.flac:  audio data is not cut on a sector boundary (sector misalignment = 1504 bytes).
(09) [Alan Menken & Howard Ashman] Les Poissons.flac:  audio data is not cut on a sector boundary (sector misalignment = 800 bytes).
(10) [Alan Menken & Howard Ashman] Kiss The Girl.flac:  audio data is not cut on a sector boundary (sector misalignment = 1440 bytes).
(11) [Alan Menken & Howard Ashman] Fireworks.flac:  audio data is not cut on a sector boundary (sector misalignment = 2240 bytes).
(12) [Alan Menken & Howard Ashman] Jig.flac:  audio data is not cut on a sector boundary (sector misalignment = 2080 bytes).
(13) [Alan Menken & Howard Ashman] The Storm.flac:  audio data is not cut on a sector boundary (sector misalignment = 176 bytes).
(14) [Alan Menken & Howard Ashman] Destruction Of The Grotto.flac:  audio data is not cut on a sector boundary (sector misalignment = 944 bytes).
(15) [Alan Menken & Howard Ashman] Flotsam And Jetsam.flac:  audio data is not cut on a sector boundary (sector misalignment = 512 bytes).
(16) [Alan Menken & Howard Ashman] Tour Of The Kingdom.flac:  audio data is not cut on a sector boundary (sector misalignment = 1184 bytes).
(17) [Alan Menken & Howard Ashman] Bedtime.flac:  audio data is not cut on a sector boundary (sector misalignment = 240 bytes).
(18) [Alan Menken & Howard Ashman] Wedding Announcement.flac:  audio data is not cut on a sector boundary (sector misalignment = 1232 bytes).
(19) [Alan Menken & Howard Ashman] Eric To The Rescue.flac:  audio data is not cut on a sector boundary (sector misalignment = 1744 bytes).
(20) [Alan Menken & Howard Ashman] Happy Ending.flac:  audio data is not cut on a sector boundary (sector misalignment = 1392 bytes).

There were sector boundary errors.


Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2646
TLH can't fix it. Keep in mind that on gapless albums medieval even kills parts of the music away.

Edit: well, TLH can make the frame boundaries fit so that CUEtools don't complain but the original will be different.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2647
Quote
how could I fix the splitted tracks so that they will be verifiable again with CUETools?

I've tried this. Some samples are discarded by that program when splitting FLAC files so unless the cuts were made where there was digital silence (zeroes), you likely won't be able to. The TOC layout is usually changed also so the track lengths are also probably wrong.

Even if the cuts were made where there was digital silence and assuming you deleted the original CDImage, you would need to know the original TOC for the CD. Then move samples or pad the missing samples with zeroes to make the track lengths correct and hope you put the correct number on each side of the cut so you don't change the offset of the track. Then it would verify.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2648
Thank you, so it seems very painful, if not impossible, to obtain the original tracks once they're splitted with Medieval CUE Splitter, or similar shitty software. So it would be better to ban it from Earth... or simply avoid it! This is because it would be impossible for tracks splitted with MCS to be repaired with CUETools, for example.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2649
I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.

Maybe this was asked before, but why was .NET chosen for CUETools' implementation? Wouldn't it have been better to use something that is portable more easily (or rather, being multi-platform from the start)?  Qt/GTK come to mind.