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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2775
I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.

EAC indicating pre-emphasis in a log, is this a new feature or something?  It surely didn't do it with versions prior to 1.0.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2776
Indeed, secure mode involves a minimum of 2 reads ... The filename thing is not a bug. ... so Test & Copy is putting unnecessary wear & tear on your drive. ...

Understood, and thanks for the confirmation that I mostly understand what I was seeing.

Quote
The rips should not be aborting unless there's a communication problem with the drive.

Well I've now installed EAC on the same platform, and it has ripped both discs of The Wall and Brubeck's Time Further Out flawlessly (i.e., all tracks extracted and converted to FLAC, metadata and cover art found and used, AccurateRip verified). 

So the external USB drive, attached to QNAP, made available to the Win7 VM works, but CUERipper-the-application has a problem with it for some reason.  That is where I'm hoping for any suggestions to gain traction on ... Logging, debug mode, anything else I can do.  Could be as simple as I'm missing something or am misconfigured.  The instructions in the wiki said unpack the folder no setup required, so that is all I did.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2777
EAC indicating pre-emphasis in a log, is this a new feature or something?  It surely didn't do it with versions prior to 1.0.

Sorry if my post wasn't clear ... One of the many reasons I would like to get CUERipper operational is that the generated CUE file is supposed to indicate pre-emphasis if it is flagged either in the TOC or the per-track subcode.  From online reading my understanding is that a CD mastered with pre-emphasis ought to have that indicated with a flag in the TOC, but there are some in the wild where it is only indicated in the subcode.

I can't find the reference at the moment, but I believe that really old versions of EAC could check/report all the detail from both TOC and subcode, but Andre Wiethoff had to remove some of this functionality because of concerns related to EU DRM regulations.  Per this chart, the current version of EAC reports pre-emphasis TOC-only, while CUERipper is listed as reporting TOC and subcode.

I'm not clear on whether EAC's indication of TOC-flagged pre-emphasis is just somewhere on the UI, or in the log, or if you have to generate a CUE file.  For CUERipper it seems to be in the CUE file (even though CUERipper is failing to rip for me right now, it does produce a CUE file).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2778
From online reading my understanding is that a CD mastered with pre-emphasis ought to have that indicated with a flag in the TOC, but there are some in the wild where it is only indicated in the subcode.

I can't find the reference at the moment, but I believe that really old versions of EAC could check/report all the detail from both TOC and subcode, but Andre Wiethoff had to remove some of this functionality because of concerns related to EU DRM regulations.

Unfortunately I don't have any of the dozen or so titles listed here to verify for myself, but I have read about this.

I'm not clear on whether EAC's indication of TOC-flagged pre-emphasis is just somewhere on the UI, or in the log, or if you have to generate a CUE file.

Unless it has recently been changed, pre-emphasis is displayed in both the GUI and the cue sheet, but not the log file.

It would be nice to have it in the log file, since cue sheets aren't all that useful for most people who keep one track per file and have no intention to burn duplicates with sub-channel information or check their lossless sources against the AR/CT databases.  Unfortunately, cue sheets are still required if you want a written record indicating the existence of pre-emphasis.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2779
Unfortunately I don't have any of the dozen or so titles listed here to verify for myself, but I have read about this.

I had seen that page before but had lost track of it, thanks for the pointer.  Unless I just haven't had enough coffee yet this morning  , it doesn't list the 1979 Columbia/CBS edition of The Wall (C2K 36183).  This page calls out that release as having pre-emphasis, so I've been testing with my copy.

EAC V1.1 reports "No" pre-emphasis for each track of both discs, but I don't believe EAC is checking the subcode.  While I haven't been successful at getting CUERipper to actually rip on my platform, it does gap-detect and create a CUE file before it starts ripping (and then fails).  The CUE is consistently saying FLAGS PRE for each track, as in:

Code: [Select]
  TRACK 01 AUDIO
    FLAGS PRE
    PERFORMER "Pink Floyd"
    TITLE "In the Flesh?"
    INDEX 01 00:00:00
    ...

So I think it is an example of the flag missing from the TOC (where EAC would have indicated it), but present in the subcode?

Quote
It would be nice to have it in the log file, since cue sheets aren't all that useful for most people who keep one track per file ...

I agree with your point, but it would only be reliable (from the standpoint of breaking out SoX deemph or some other tool to correct it post-rip) if the log reported pre-emphasis flag(s) from both the TOC and the subcode, correct?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2780
So I think it is an example of the flag missing from the TOC (where EAC would have indicated it), but present in the subcode?
Yes.
Quote
I agree with your point, but it would only be reliable (from the standpoint of breaking out SoX deemph or some other tool to correct it post-rip) if the log reported pre-emphasis flag(s) from both the TOC and the subcode, correct?
More reliable, yes.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2781
Hello!
I found a bug in the CueTools.Flake.exe
I am converting files from various formats to flac using Flake encoder included in CueTools (CUETools.Flake.exe)
After encoding some files (not everyone) I get MD5 hash error ("Ошибка верификации").
When I verify it with reference flac.exe I get "ERROR, MD5 signature mismatch"
My command line is: -11 --lax -b 4608 -t "search" -s "search" -r 8 --vbr 4 -l 32 -m "akaike" -e 32 --window-method search --max-precision 1,1 -P 0
I found that encoded file gets corrupted when using --vbr 4. Without this option I get no errors.

I uploaded one WAV track to the share
https://drive.google.com/file/d/0BzoOc80ZSA...iew?usp=sharing

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2782
New user attempting to use CUERipper ... This thread seems current, but someone please let me know if I should put this elsewhere.  I'm encountering:
[blockquote]Exception: Error Reading CD: IoctlFailed[/blockquote]in a fashion which seems different from what I've been able to find by searching.

I've been an EAC user on an old machine at home that is failing, so I've brought up a new platform and wanted to try CUERipper at the same time.  The new platform is:
  • A virtual machine running Win7 Home Premium x64 SP1, 6GB of RAM
  • The VM is hosted on a QNAP TS-451 NAS (x86 dual-core CPU, host OS is "QTS 4.1.4")
  • Lite-On eTDU108 external DVD-ROM, USB 2 connection to the TS-451 (no outboard hub), drive assigned to the VM
  • CUETools 2.1.5, downloaded this morning. Stock configuration except for: Option changes for metadata search - extensive, detailed log - true; changed from image to tracks mode; set Test & Copy; and changed output path template
my discs for testing are Pink Floyd, The Wall (Columbia, C2K 36183).  Previously ripped years ago via EAC, sitting on an indoor shelf ever since. I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.  Wanted to see CUERipper report it (and then experiment with fixing it).

So I launched CUERipper, and loaded a disc once the window was up.  CUERipper identified the read offset (matching what I had seen in a web site search for this drive), read the disc metadata and track titles, and finds 30 CUETools DB matches and 78 AccurateRip matches.  This is looking very promising!

Hit the "Go" button ... Status bar shows Detecting drive features ... followed by Detecting gaps ...  After gap detection completes I see Ripping @nn.mm ..., then Ripping @nn.mm (retry 1)... (if I understand correctly, retry because I'm in "Secure" mode?), then shortly after it switches back to another Ripping @nn.mm ... (Track #2?) the rip fails with the Error reading CD.  Checking the folder I see only the .CUE file.  This seems to be deterministic behavior on both discs.

Switched off Test & Copy, repeated the experiment.  This gets me further into the rip before encountering the error.  The alternation between Ripping and Ripping (retry 1) was still happening, 4-8 times (across multiple tests), but when I check the target folder I see only the .CUE file and sometimes 01. In the Flesh_.flac (note that CUERipper shows the track title as In the Flesh?, so the file name in the folder differs slightly from the %tracknumber%. %title% template in the options).  When it fails only 4-5 alternations (tracks?) into the rip I see just the .CUE file, if it goes further I see the .CUE and a single FLAC.  Haven't ever seen more than the first track's FLAC file.

Similar results on the other disc in the set.  The behavior isn't deterministic, how deep into the rip I get varies (as long as Test & Copy is not selected).  Changing to either Burst or Paranoid mode seems to make the failure happen sooner.

So I'm hoping this is a known problem with known solutions to try, and my "Google-fu" just isn't good enough to find them.  Failing that, if anyone involved in CUERipper development can tell me how to enable more logging or debug information to get some traction on the problem, I'll certainly willing to give it a go.  I'll also do an EAC installation on the VM and give it a try this evening, to see if the drive fails to work with any ripping software.

Thanks in advance for any advice or pointers,
Alan


I have not the solution. But I have the same problem. Cueripper on Linux (under Wine) behaves exactly like (Cuetools works perfectly)
I guess the Linux kernel (most NAS implement Linux) does not support certain calls (from Cueripper) to the device. Or that the VM (and Wine) do not correctly translate these calls...
Maybe someone who knows about low-level code can respond
Sorry for my english

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2783
I have not the solution. But I have the same problem. Cueripper on Linux (under Wine) behaves exactly like (Cuetools works perfectly)
I guess the Linux kernel (most NAS implement Linux) does not support certain calls (from Cueripper) to the device. Or that the VM (and Wine) do not correctly translate these calls...
Maybe someone who knows about low-level code can respond


remenor,

I think my NAS is using KVM/qemu for supporting VMs, but I don't have anywhere near enough Linux depth to tell you how different or common that would be with the Wine code.

Since my failure point is variable, I suspect something modal/timing-related, where a returned status isn't translated correctly, or CUEripper's logic attempts some API call that doesn't work for the first time during a rip (as a made-up example:  reducing speed for a retry attempt). If the problem was just an unsupported call that is part of CUEripper's normal sequence of events, I would expect my failure point to be completely consistent.

I was also hoping for some guidance on how to debug this problem, but I've looked at the history on the source repository, and there doesn't seem to be any action after 2015-02-25 (most changes seem to be 2014 or older).  Could be that the developer(s) are otherwise occupied.

I entertained the notion that I might be able to find and enable any code in the application for additional logging, so I borrowed a machine with Visual Studio 2012, downloaded a local version of the code, and attempted to build the project.  Unfortunately VS2012 griped about having to convert from a VS2010 project type, and after doing that generated 30+ errors and 80+ warnings.  This isn't really in my skill set, I don't think I'll be able to get to a clean build.  I assume from the wiki that its a .NET application, and AFAIK .NET is such an expansive collection of libraries that "learning cliff" may be a more appropriate term than "learning curve."  If you happen to have .NET skills, you might find the source more useful than I did.

Fortunately I'm not completely out of luck, since EAC is working in my environment.  You might try EAC on Wine if you don't have any other ripping solution.

Regards,
Alan

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2784
I have a serious problem!

I would like to report a bug.

The Cuetools plug in for EAC treats those albums:
http://www.metal-archives.com/albums/Moonl...of_Guilt/491107
http://www.metal-archives.com/albums/Moonl...of_Guilt/134588

As identical discs and while ripping the english-language version the plugin compares the results with polish-version, thus making all as "No match", the same occurs with accuraterip plugin in EAC, it compares those two discs, so the obcious result is, that the second tip is inaccurate entirely.

So CTDB plug-in has serious issues with albums that were released with vocals in different languages, seriously, is the same bug present on Kraftwerk's Komputerwelt/Computerworld when ripping those separate CDs with the same music, but different vocals?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2785
If the two versions use the same CD layout (same TOC) then both CD versions will be stored under the same AccurateRip ID and the same CTDB TOCID but with different checksums. If one of the CD versions shows zero results then likely no one has submitted that one yet.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2786
Also when enough people submit this 2nd disc, they will both co-exist in AccurateRip.

It is not a bug, just your disc is not yet in the database.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2787
As fot the Polish version, the Accuraterip confidence was 2, and the disk was not present in CTDB database, so it was uploaded.
The englidh version had confidence 2 claiming that the whole rip is inaccurate, but it did mention that the pressing might be different, which is obvious, as those are two different albums, the CTDB results were "(0/1) No match".

Full logs I can add, if it would be useful.

Both CDs ripped properly, so my post was just a notification of the issue.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2788
The English version was also submitted to the CTDB.

The (partial) AccurateRip ID for BOTH versions is 0011e2c9-00775798-6a0e1008
The CTDB TOCID for BOTH versions is JFlEmyJUDSuIMKB0KPRyGf7V_uU-
Because the TOCs match, BOTH versions of the CD coexist under the same ID. This is not a bug.

When you ripped the second CD, the CTDB compared it to the first CD (which it found under the same TOCID and did not match) so you received "(0/1) No match" and the second CD was submitted.
If you were to re-rip both CDs right now the CTDB results would be "(1/2) Accurately ripped" for both CDs (assuming the re-rip matched the original and no one else submitted one of the versions) and the Submit result would be "Already Submitted".

Both versions of the CD will also coexist in the AccurateRip DB under the same ID (not a bug) once the English version gets added. It appears that only the Polish version may exist right now.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2789
As fot the Polish version, the Accuraterip confidence was 2, and the disk was not present in CTDB database, so it was uploaded.
The englidh version had confidence 2 claiming that the whole rip is inaccurate, but it did mention that the pressing might be different, which is obvious, as those are two different albums, the CTDB results were "(0/1) No match".


That is not a "bug", it is just that the "Inaccurate" term is sometimes imprecise. You ask the databases to have human knowledge on why the audio signal is different.

If you press/burn two three CDs with the same table-of-contents, where
-> CD#2 is like CD#1 except you have used sandpaper on it and gotten an unbelievable number of errors, and
-> CD#3 simply has a different audio signal,
then all the database can know, is that the CDs have the same table-of-contents and different audio.

What if you took CD#3 and ran it through a DSP? An EQ? A karaoke effect array?  The databases cannot know.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2790
Thus the mechanisms of database should be made more precise to distinguish two CDs with different music, but the same TOC.

I will not rerip it several times, so that databases would have few results, I could however rip them form several different workstations, or hope more people will tip their CDs and submit them to database...

The important thing is, there were no errors during ripping, so tracks are of avveptable quality, considering they are mp3s...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2791
Thus the mechanisms of database should be made more precise to distinguish two CDs with different music, but the same TOC.


It is not useful for what AccurateRip is good for, namely to verify that someone has gotten the same as you. It is only good for explaining why someone got something different. 

And while it is likely doable now, as audio fingerprint algorithms are getting better, there is no way you can retro-fit audio into old entries anyway.



I will not rerip it several times, so that databases would have few results, I could however rip them form several different workstations


You will not but you however still will ... ?


The important thing is, there were no errors during ripping


Again, AccurateRip cannot verify that unless someone has gotten the same result. If the result is different for whatever reason, it cannot verify.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2792
CUETools is failing, reporting L-EC Uncorrectable Error on one track.

Feature requests:
- Option to skip this error and still rip as much of the track as possible (if possible?)
- Option to skip track / select which tracks are ripped.

I've downloaded the source code for CUETools and modified it to skip the track throwing the error. I will see if I can also find a way to ignore this error.

CUERipper not detecting gaps

Reply #2793
I'm soon to embark on an archival project involving securely (as possible) ripping hundreds of precious audio CDs. Before I start properly, I've been trialing a few different 'secure' ripping utilties, and I really like the feature set, as well as the simplicity of CUERipper, but I've already encountered an issue on one of the first CDs I've tried to rip.

Basically, CUERipper seems to be unable to detect the gaps on the CD in question, which is a normal factory-pressed disc. So I then tried ripping the disc in Exact Audio Copy, which was able to detect the gaps.

I've uploaded the logs from each program:

CUERipper
Exact Audio Copy

Does anybody know why CUERipper is not detecting the gaps? It's a shame because I was hoping to rely on CUERipper as my primary CD ripping tool.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2794
@knubbze     Since both programs are doing the same thing, "appending gaps to previous track", I don't understand the problem. Is there a reasion that you must have the length of the gap?
Glass half full!

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2795
@knubbze     Since both programs are doing the same thing, "appending gaps to previous track", I don't understand the problem. Is there a reasion that you must have the length of the gap?

Well, I just wanted a perfect (as is possible) replication of the audio CDs, in case  ever want to burn a copy in the future (unlikely, but possible). For this particular CD with 'standard' gaps you are correct that it doesn't really matter, but in cases where CDs have 'index 0' pregaps (i.e. this CD), I figured that it may be a problem.


Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2797
*looks at page count and recalls staggering number of topic changes in this thread*
*considers possibility that greynol is joking*

Anyway, perhaps I should be more direct:

CUETools warning the user that the audio is not Red Book is good, but refusing to operate on it seems like an unnecessary restriction.

Agree 100%.

Same problem today, I was going to split a hires file and I can't do it with Cuetools just because the program is restricted to reedbook. (!) But at the same time I can use ALL the lossless encoders from same program to work with those hires files... makes no sense to me.

I hope lifting that restriction will be taken into consideration too.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2798
Does anyone happen to know why I can rip a CD just fine but when I rip a CD through a Windows 7 VM, none of the rips verify as accurate? The VM is a guest of the machine that rips the CD accurately so all of the hardware is the same and I manually entered the proper drive offset in the VM.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2799
I manually entered the proper drive offset in the VM.
Are you sure the VM environment is providing direct access to that drive? An emulated drive will likely have a different read offset.
korth