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 1894311 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 #2150
Hmm something I noticed: when verifying albums with CUETools, it looks at both AR and CTDB and reports the result. However when encoding it only checks AR.
Is there an option I'm missing or is it intended?

edit: also, I can't seem to find where I can disable caching. For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2151
Quote
Is there an option I'm missing or is it intended?
This is normal behavior. There is no 'Use CTDB' checkbox under 'Mode' on the GUI when 'Encode' is selected under 'Action'.
Quote
also, I can't seem to find where I can disable caching.
http://www.cuetools.net/wiki/CUETools_Adva...tings:_Advanced
Quote
For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...
Are the old tags still in the CUE file?
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2152
You're right. Though it's kinda a bummer, now I will have to re-verify my whole library after converting it to single tracks :|
One more thing, the "copy albumart tags" option ignores any covers in .png format...

edit: I was about to post that I don't have a "cache" option there when I noticed the scroll bar was not in the topmost position. It was aligned perfectly so that the list started at "Cover Art". And the weird thing is, when I adjust the scroll bar, close the dialog and reopen it, it returns to starting at "Cover Art". And it also only happens when you have the "Cover Art" section expanded. No wonder I couldn't find it lol

edit2: no, both .cue and the files had the same tags. In the end I ended up renaming the folder the files were in temporarily and it saw the new tags.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2153
Quote
One more thing, the "copy albumart tags" option ignores any covers in .png format...
When I tested 'Cover Art Files', jpeg, png, gif and bmp didn't appear to work (only jpg). I already reported this.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2154
Is there a way to tell CUETools to look for audio files corresponding to a .cue in a different folder? I think this could be possible by creating a custom script, but I couldn't find any reference which variables can be used etc. Something like SetWorkdir="..\" maybe?

In my case, I have the following structure:

album\files\album.cue
album\track 01.flac
...

I apologize if it was asked already, but I can't seem to be able to find anything. Would it be possible to additionally filter by .cue, so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks? Thanks in advance.

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2155
I'll defer on the first part.
Quote
In my case, I have the following structure:[blockquote]album\files\album.cue
album\track 01.flac[/blockquote]
AFAIK, CUETools expects the CUE and EAC LOG to be in the same folder as the audio files. However, if you set the full path for each audio file in the CUE file, CUETools can process that CUE file from another folder (and EAC LOG if in same folder as CUE).
[blockquote]FILE "c:\mymusicfiles\album\track 01.flac" WAVE[/blockquote]
Quote
so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks?
You can select to use only the CUE files during batch encoding.
Hint#1: Windows Search c:\mymusicfiles and subfolders for *.cue. Highlight the ones you want to use from the results. Drag them into 'Drag'n'drop mode' window.
Hint#2: Use 'Multiselect Browser mode'. Expand mymusicfiles and desired subfolders. Check the boxes next to the desired CUE files.

(naturally 'c:\mymusicfiles' is only an example of any folder containing music files.)
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2156
I noticed two possible bugs with CueRipper:

1. It does not remember choice of output format (always goes back to flac, when restarting the program)
2. Album art is always embedded on rips, even when de-selecting the option to do so

I've noticed the above when ripping to ALAC format.

Best Regards.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2157
Must be something on your end. Mine saves the format fine, didn't try to disable album art embedding, but I think that might be related to CUETools seemingly not saving your settings. If you don't have user profiles enabled, it probably tries to write to C:\, which would fail if it doesn't request administrative privileges. This is assuming you're on win vista or later with UAC enabled.

@Korth: thanks, filtering by .cue in explorer sounds like a good idea. Ticking everything in browser mode isn't so convenient when converting the whole library with ~200 folders.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2158
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2159
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.


Thanks, but I may have a different problem.  Other settings seem to save fine.  When I open the settings file it does show the embed album art parameter with a value of 0 but the resulting alac files still have the art embedded within.  Unless either Windows 7 or iTunes is embedding the image from folder.jpg on each track file.

If that's the case, I'll still be scratching my head as to why the format defaults to flac when I restart CueRipper.  I don't really see this option in the settings file, but it happens to be the first option in the drop-down menu and maybe that's why it always start there.  It's no big deal but sometimes I forget to set it back to .m4a when I restart CueRipper and start ripping into flac instead of .m4a.

If somebody can point me to this parameter in the settings file, that would be great.

Thanks again.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2160
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2161
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.

Thanks for confirming that.
I do have DefaultLosslessFormat set to .m4a but as you found out, CueRipper still defaults to .flac container when starting up.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2162
CUETools complains about 2 "albums", one is a digital only release with a sample rate of 48khz, another one is a game rip with a sample rate of 22,5khz. In both cases it says the format is invalid... Files decode fine in foobar though, I assume CUETools only handles 44,1kHz files?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2163
Yes, 16-bit 44.1 kHz Stereo CD-DA (Red Book) for input.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2164
CUERipper's handling of AccurateRip and CTDB submissions still mystifies me. Today while experimenting with burst mode, I got "AR: rip accurate (44/44), CTDB: disk not present in database, insufficient quality."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:00:37 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

Read mode              : Burst
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
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.32 |  8:43.33 |        32    |    39289 
        2  |  8:43.65 |  7:45.30 |    39290    |    74194 
        3  | 16:29.20 |  8:58.57 |    74195    |  114601 
        4  | 25:28.02 |  6:48.15 |    114602    |  145216 
        5  | 32:16.17 |  7:01.25 |    145217    |  176816 
        6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

    Pre-gap length  0:00:02.42

    Peak level 99.4 %
    Track quality 100.0 %
    Copy CRC E61B076B
    Accurately ripped (confidence 46)  [D94B89C4]
    Copy OK

Track  2

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

    Pre-gap length  0:00:03.73

    Peak level 99.7 %
    Track quality 100.0 %
    Copy CRC 510F5D70
    Accurately ripped (confidence 46)  [151FCAF7]
    Copy OK

Track  3

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

    Pre-gap length  0:00:02.84

    Peak level 100.0 %
    Track quality 100.0 %
    Copy CRC D05202B6
    Accurately ripped (confidence 45)  [EA4F7DF1]
    Copy OK

Track  4

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

    Pre-gap length  0:00:04.42

    Peak level 99.2 %
    Track quality 100.0 %
    Copy CRC 7181379B
    Accurately ripped (confidence 46)  [E419B7F9]
    Copy OK

Track  5

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

    Pre-gap length  0:00:03.73

    Peak level 99.9 %
    Track quality 100.0 %
    Copy CRC 71C4A87B
    Accurately ripped (confidence 46)  [5D270E84]
    Copy OK

Track  6

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

    Pre-gap length  0:00:03.73

    Peak level 99.6 %
    Track quality 100.0 %
    Copy CRC C0C9DC68
    Accurately ripped (confidence 44)  [9E561A14]
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why "insufficient quality" for this?

So then I re-ripped in Secure mode, and sure enough, it was acceptable: "AR: rip accurate (44/44), CTDB: disk not present in database, 0Z0vBojTm3ENuDvKLGSe4daWlEw- has been uploaded."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:10:17 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
CUETools DB: insufficient quality.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

Read mode              : Burst
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
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.32 |  8:43.33 |        32    |    39289 
        2  |  8:43.65 |  7:45.30 |    39290    |    74194 
        3  | 16:29.20 |  8:58.57 |    74195    |  114601 
        4  | 25:28.02 |  6:48.15 |    114602    |  145216 
        5  | 32:16.17 |  7:01.25 |    145217    |  176816 
        6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

    Pre-gap length  0:00:02.42

    Peak level 99.4 %
    Track quality 100.0 %
    Copy CRC E61B076B
    Accurately ripped (confidence 46)  [D94B89C4]
    Copy OK

Track  2

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

    Pre-gap length  0:00:03.73

    Peak level 99.7 %
    Track quality 100.0 %
    Copy CRC 510F5D70
    Accurately ripped (confidence 46)  [151FCAF7]
    Copy OK

Track  3

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

    Pre-gap length  0:00:02.84

    Peak level 100.0 %
    Track quality 100.0 %
    Copy CRC D05202B6
    Accurately ripped (confidence 45)  [EA4F7DF1]
    Copy OK

Track  4

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

    Pre-gap length  0:00:04.42

    Peak level 99.2 %
    Track quality 100.0 %
    Copy CRC 7181379B
    Accurately ripped (confidence 46)  [E419B7F9]
    Copy OK

Track  5

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

    Pre-gap length  0:00:03.73

    Peak level 99.9 %
    Track quality 100.0 %
    Copy CRC 71C4A87B
    Accurately ripped (confidence 46)  [5D270E84]
    Copy OK

Track  6

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

    Pre-gap length  0:00:03.73

    Peak level 99.6 %
    Track quality 100.0 %
    Copy CRC C0C9DC68
    Accurately ripped (confidence 44)  [9E561A14]
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why wasn't the burst rip acceptable? It was no better or worse than the secure rip; the output was identical.

And why does the secure rip's .accurip log say "insufficient quality"?! Shouldn't it be the other way around?

Is it unreasonable for me to expect things to make more sense than this? Would it help to enable the detailed log?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2165
Burst rips are not acceptable (insufficient quality) for CTDB, because if your drive doesn't return C2 errors reliably, there can be any amount of undetected errors in burst mode.
You only know that the rip was actually good because it matched AccurateRip database (on which CTDB no longer relies for various philosophical reasons), and because it matched your second rip (to which it couldn't compare it because it was not yet made and time travel is not yet invented).

Somehow .accurip files have mixed up it seems; The result from the first rip crept up into the second log. I will need to look into that.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2166
Did you post the same rip log twice? Both say "extraction logfile from 10. April 2013, 18:00". If not, there is a bug in CUERipper where some of the log data isn't cleared if you rip the same disc a second time without reloading the disc. [Reminder of bug to Gregory]

'Burst' mode is one pass (if no C2) and one pass is insufficient quality to submit when no previous records of that disc exist in the CTDB (AccurateRip data is ignored). I think if you had enabled 'Test and Copy' and both CRCs matched then the quality would be sufficient to submit a new disc record (but Gregory would need to confirm this). 'Secure' mode is a minimum of two passes so the CRCs were double checked and the quality was sufficient to submit a new disc.

Edit: [Gregory beat me to it]
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2167
Thanks for the responses.

The .log files are indeed identical; I didn't post the same one twice (well, I suppose it depends on how you look at it ). In between rips, I renamed the output folder, so it's not a case of an existing file being in the way.

The .accurip files are also identical, except for the date/time and "CUETools DB: insufficient quality." appearing erroneously in the secure rip rather than the burst rip.

How does CUERipper determine whether to make use of C2 pointers?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2168
Speaking of logs, why are there sometimes entries like:
accurate rip id xxxx found

track1 0+0/0, rip not accurate
...

Can't post the actual log because I can't find the disc which had it atm =|

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2169
ChronoSphere,
See [a href='index.php?act=findpost&pid=743235']this post[/a]
Quote from: Goratrix link=msg=0 date=
Do I interpret it correctly, that between November and today, there has been a new submission for this disc, with different data than the previous one, and therefore both of them have been moved to "limbo"? But the disc ID itself stays in the database, so we get this weird 0/0 result?

and this dbpoweramp thread.
Quote from: spoon link=msg=0 date=
A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db. You rip correctly get [AAAAAAAA], submit, now neither results are in the db, 3rd guy rips and submits [AAAAAAAA], now only [AAAAAAAA] appears.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2170
I'm really trying hard to switch full time to Linux but I find myself using this program a lot (I have Windows 7 in VirtualBox).

I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

Sorry if you find this request an annoying one (like I said I'm sure you've heard it before) but Linux is finally catching on now in a big way and with STEAM now on Linux it will just be getting more and more popular so please consider it.

Thank you!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2171
I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

It doesn't get a lot of testing, but it should work with MONO, and work almost as good as native applications. Theoretically you can even build a static Linux binary from it using mkbundle from mono-devel. It will compile it to a native application more or less.

And the bit about it only supporting WAV is probably outdated. There are managed FLAC and ALAC codecs in cuetools. If it doesn't work for some reason, it probably doesn't take much work to fix it. It's just a matter of finding time for it, or finding someone willing to find some time
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2172
I'm currently on linux as well (Linux Mint 14) and the best way around I've found to use CUETools has been with wine + the required .Net libraries installed through the command winetricks. Everything I tested works great so far (transcoding to flac from different formats using libflake, verifying with Accuraterip/CTDB, HDCD decoding) and the only small issue was to set wine envirorment to work as 32bit in my x64 computer or .Net installer would refuse to run.

I also tested CUETools with mono, but the experience wasn't that good. Wine + mono for windows had a very annoying issue. CUETools seemed to work fine, but the progress bar at the botton just disappears with all the info regarding AccurateRip and CTDB, whereas with Mono for linux (no wine needed), the GUI was completely screwed. Could never find the Go button to run it, plus only WAV decoding still applied as it was the only encoder available.

Would love to see a native version for linux though (and CUERipper too!)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2173
Any idea the correct setup to add fhgaacenc?

I've copied the required files into Cuetools directory and added this:

Path: fhgaacenc.exe
Parameters: --vbr %M - -o %O
Modes: 1 2 3 4 5 6

But it's not working

Error: "fhgaacenc.exe has exited prematurely with code 0: The pipe has been ended."

It seems my parameters are wrong

EDIT: Parameters: --vbr %M - %O  works fine

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2174
In addition to the features requested, if any, please make the next version completely portable with the option to save the configuration folder inside the app folder. Thanks.