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 1907667 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 #950 –
Some additional notes:

Actually, even EAC doesn't handle various artists albums optimally. When the "Various Artists" option is ticked it changes the album artist's name to "Various". Ideally it should allow to use a global album artist name.

CUERipper could do this better. It could also automatically write the "Album Artist" file tags when the "tracks" ripping mode is enabled.

As a side note, apparently EAC stupidly adds the folder path to the filenames in the CUE sheet when its filename rule is set to create folders. If the cue sheet is saved in the audio files' folder the path will be incorrect. Fortunately CUETools can fix that easily. CUERipper does this correctly.

After ripping is finished CUERipper shows this:



"confidence 3" is obviously the number from AR db (two) + one additional from my first rip with CUERipper (after my second rip of the same CD that number increased to four), but what does "8400 has been confirmed" mean?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #951 –
Quote from: Alex B on
As a side note, apparently EAC stupidly adds the folder path to the filenames in the CUE sheet when its filename rule is set to create folders.
While I like to keep CUEs in the same folders as the files, I wouldn't condemn the idea that cues can be stored at the root of a folder structure as stupid.  That said, there is certainly room for improvement; such as simply presenting users with sensible options.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #953 –
Quote from: Alex B on
"confidence 3" is obviously the number from AR db (two) + one additional from my first rip with CUERipper (after my second rip of the same CD that number increased to four), but what does "8400 has been confirmed" mean?

This is a message from CUETools database, that entry 8400 has been confirmed, i.e. it's confidence number increased by 1.
I know it's not very user friendly, but didn't decide yet what to do about it. Either show the long CTDB id instead of entry number, or get rid of this technobabble completely.
By the way, i tried to add some support for Various Artists.
In updated CUERipper 2.0.8 when you right-click on a freedb release, you can choose 'Various Artists' from the menu and it will try to parse it as a Various Artists album.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #954 –
Is it possible to set CUETools to use id3v2 tags only? Currently it adds id3v1, v2 and APE to the mp3 files.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #955 –
Hi there, did try your sample file and ir works on the iphone 3gs, will try again with the updated cuetools. thanks again!

PS: will be trying to get pcutmp3 to work with cuetools as an external encoder (for lossless mp3 splitting)... is anyone using this with cuetools also?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #956 –
I don't think it's possible.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #957 –
Quote from: Gregory S. Chudov on
I don't think it's possible.


Just tried and it's not working indeed...
Usually I use a batch file with the following:

Quote
java -jar pcutmp3_098b.jar --cue %1 --dir "%~dp1
pause
exit


... and then just drag the cue file onto the batch file.

using the command line the parameters are

Quote
--cue <cue-filename>.cue


do you think you can help? this would be the icing on the cake because pcut has no batch processing and through cuetools this would be possible.
also, perhaps this could be somehow included in cuetools because although this is for mp3... it IS a lossless 'encoder' (no encoding actually, I know) and it's a shame one has to recompress mp3 to split...

thanks again, cheers

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #958 –
Quote from: Gregory S. Chudov on
... By the way, i tried to add some support for Various Artists.
In updated CUERipper 2.0.8 when you right-click on a freedb release, you can choose 'Various Artists' from the menu and it will try to parse it as a Various Artists album.

Thanks. I ripped some additional "Various Artists" discs with the updated v.2.0.8. My findings:

- data is present in freedb:
"Various Artists" can now be set. It is difficult to go back to the Artist / Track view for checking and possibly editing the entries (the view can be reset by ejecting and reinserting the disc or by switching between the drives if you have more than one drive). The Album Artist tag is not added to the track files.

- data is present in MusicBrainz:
Works as before. The Album Artist tag is added to the track files. However, there is no way to see or edit the track artists' names.

- data is not present in the online DBs:
There is now way to type the correct tags if the album has multiple track artists.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #959 –
Quote from: Gregory S. Chudov on
Thank you. I think i fixed it. Try the updated http://www.cuetools.net/install/CUETools_2.0.8.rar

Yes, that seems to work. Thanks!

Quote from: Gregory S. Chudov on
I wonder what software created such a file. It had a slight error in it's mpeg boxes, which shouldn't affect anything so i just ignore such errors now.

It was either CueTools or dBpoweramp. Those are the only tools I use to convert to Apple Lossless. If it helps, I could do some new conversions, and tell you which ones used CueTools and which ones used dBpoweramp, so you can see the differences if any.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #960 –
Quote from: fadsplat on
... It was either CueTools or dBpoweramp. Those are the only tools I use to convert to Apple Lossless. If it helps, I could do some new conversions, and tell you which ones used CueTools and which ones used dBpoweramp, so you can see the differences if any.

I wonder if your problem files are encoded with an old version of dBpa's ALAC encoder. Here is a quote from my old reply at the J. River forum (http://yabb.jriver.com/interact/index.php?...27262#msg327262):

Quote
I was puzzled by the fact that sometimes ALAC decoding through DS works fine and sometimes not.

After running some tests with various ALAC files I found out that an old version of dBpoweramp's ALAC codec creates different tags than the latest version or iTunes. The old version writes tags to the end of the files and the latest version of the dBpa codec and the current iTunes build write them in the beginning of the files. Possibly there are other differences too.

Apparently the DC-Bass Source filter cannot decode files that are created with the old version of the dBpoweramp codec. On the other hand, all files that were created with the latest version of the dBpa codec or iTunes decoded without problems with various DS players. I verified this with MC, WMP, Zoom Player and Media Player Classic.

Possible solutions (these all work for me, but I don't know if you are experiencing the same problem):

- Use the latest version of dBpa's m4a codec or iTunes for encoding the files.
- Fix the old files by using dBpa's "m4a Optimize" tool (it's included in the m4a Utilities codec)
- Fix the old files by using Mp3tag's "Optimize m4a" feature (select the files > right-click > Optimize m4a). Mp3tag is available here: http://www.mp3tag.de/en/


EDIT: fixed the link

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #961 –
It must have been dbPowerAmp then.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #962 –
Quote from: Alex B on
I wonder if your problem files are encoded with an old version of dBpa's ALAC encoder.

No, not very old. It's version 13.3.

Added: some could have been converted with an earlier version, but even that would not have been very old. It would have been the then-current version last fall, as I think that was when I first began using dbPowerAmp.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #963 –
Quote from: fadsplat on
No, not very old. It's version 13.3.

Added: some could have been converted with an earlier version, but even that would not have been very old. It would have been the then-current version last fall, as I think that was when I first began using dbPowerAmp.

In general, the dBpa codecs are developed separately from the main application. The current "m4a codec" is Release 9. However, the old version I am referring is much older than "last fall" (my quote is from the year 2008), so probably your issue is different (also I don't know if the decoder in CUETools would have the same problem with "old dBpa ALAC" files).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #964 –
I have a question regarding the filename correction in the cue sheet of multi-volume releases. How does CUE Tools do that?

I mean, why doesn't it use the tracks of CD 1 for the cue sheet of CD 2?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #965 –
It groups files by DISCNUMBER or ALBUM tag. It chooses the group which has the right number of tracks, but fails if two discs have the same number of tracks.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #966 –
Thanks for the new version, specially thks for refocusing on Cuetools after playing with flacuda & libFlake which are not as important to me (I don't use them & IMHO Nvidia is dying).

I like the displaying of the decoding speed, hopefully it will make people realize why flac -4 is great
Also I was happy to fix my first bad rip with the CTDB database

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #967 –
I tried using CueRipper for the first time (under Windows 7) and when I clicked on Go it started the "Detecting drive features..." part with a green bar at the bottom right, but after a short while there was an error message box. The box was titled "Exception" and the message said:
==============================
Exception: failed to autodetect read command
BEh, 12h, , 16 blocks at a time: ILLEGAL MODE FOR THIS TRACK
(1029.6018ms)
==============================
The last two lines are repeated 5 more times with different hex numbers in place of 12h.

This might look like a drive or CD problem, but I had just ripped the same CD with the same drive using dBpoweramp (and Accuraterip confirmed the rip was OK). So I'm wondering where this error might have come from or if it can be fixed somehow.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #968 –
I am wondering if it's normal to have a rip that is not accurate with a confidence 8 against AR database but accurate with confidence of 6 against the CTDB database ? (Sorry if it's a dumb question the CTDB is new to me ... maybe it has to do with the different strength of checksums or something like that afterall, I dunno)

Code: [Select]
[Verification date: 28/04/2010 17:39:43]
[AccurateRip ID: 000fd7dd-00722687-700a2d09] found.
[CTDB TOCID: AniLFC63ug3HyUZxQ1DzcQ0VzTk-] found.
		[ CTDBID ] Status
		[e581014a] (6/6) Accurately ripped
Track	[ CRC	] Status
 01	[8014e620] (09/09) Accurately ripped
 02	[20f57892] (09/09) Accurately ripped
 03	[b0c6bdd5] (09/09) Accurately ripped
 04	[84196078] (09/09) Accurately ripped
 05	[445d8bbc] (09/09) Accurately ripped
 06	[81485ad9] (09/09) Accurately ripped
 07	[903ad830] (09/09) Accurately ripped
 08	[0681f962] (09/09) Accurately ripped
 09	[1245a213] (08/08) No match but offset

Track Peak [ CRC32  ] [W/O NULL] 
 --  100,0 [0C27D7B0] [7AAC01AB]		   
 01  100,0 [93437FAD] [D3D30B3F]		   
 02  100,0 [A639BAAB] [E0A0530A]		   
 03  100,0 [CC764F44] [79B5834C]		   
 04  100,0 [5E3F117F] [8F5D117E]		   
 05  100,0 [AC4F224D] [FA59489B]		   
 06  100,0 [EBB0CB9A] [B31A84D6]		   
 07  100,0 [266BD157] [34138324]		   
 08  100,0 [AE18C50A] [111E8DA2]		   
 09  100,0 [9D767443] [B12C017E]

Edit:
Also, I don't really understand the difference between CTDB TOCID and CTDBID, I understand CTDB TOCID is a sum that use the TOC to identify the CD but I thought CTDBID was the whole checksum of the CD ... so I don't understand the name CTDBID, is it a checksum or an ID ?
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #969 –
Quote from: sonofdbn on
Exception: failed to autodetect read command

That means that your CD drive model is not supported by CUERipper at this time  What is your CD drive model?

Quote from: sauvage78 on
I am wondering if it's normal to have a rip that is not accurate with a confidence 8 against AR database but accurate with confidence of 6 against the CTDB database ?

I'm fairly certain that your rip contains errors only in the last few sectors. AccurateRip ignores last 5 sectors, CTDB - last 10 sectors.

Quote from: sauvage78 on
I don't understand the name CTDBID, is it a checksum or an ID ?

It's both. It's a CRC32 checksum of the whole CD except for a few sectors ignored due to offsets, and together with tocid it is used as an id of the database entry that corresponds to this CD's contents.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #970 –
Quote from: Gregory S. Chudov on
I'm fairly certain that your rip contains errors only in the last few sectors. AccurateRip ignores last 5 sectors, CTDB - last 10 sectors.

EAC had a bug that could have easily caused the discrepancy.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #971 –
Thks for the answers,

As I discussed with Greynol the other day, I already find 5 Frames a little too big for AR (4 is already perfect IMHO), 10 frames for CTDB seems increadibly huge to my understanding ... it would have been nice ... (& natural) if AR & CTDB would have both used the same numbers ... I don't know if there is a technical explanation behind this difference but it would have been easier for everybody to do just like the AR database IMHO.

There is another strange behavior that is annoying me even if it might be normal. CTDB reported to me that two of my rips were enhanced CD when the old way of detecting enhanced CD (without log) doesn't detect them as enhanced CD. I tried to re-check with the datatrack length that CTDB is giving me, twice it didn't match against the CTDB (It matched once against the AR database after fixing the datatrack length while it didn't match without the length). Maybe I was unlucky (I know these rips have a high probability of scratch so I cannot really conclude anything from the fact that they don't match against CTDB, I will continue to test this as I find more rips like this in my collection) ... but my actual understanding of this result is that it means that there is an existing pressing with a datatrack which is the one in the CTDB & another pressing without which is mine. But something I don't understand is how these two pressing can have the same CTDB TOCID (unless I am wrong & these two supposed pressings are a single pressing) when one is detected by the CTDB as an enhanced CD & the other not detected as an enhanced CD by the old methodology based on cue sheet analysis.
Is the old way of detecting enhanced CD always right (even if it cannot guess the exact length without a log) or can it analyse an enhanced as a not enhanced CD by misstake (specially without a log) ?
I am asking because I am a little lost there. I don't know if the old method was always accurate about the presence or not of a datatrack so now my old .accurip log (based on AR database & cue sheet info, no log info) seems to conflict with my new ones (specially the CTDB added info).

At a lesser level (I only found 1 case so far) I noticed the same kind of conflict with the presence/length of pre-gap.

Code: [Select]
[Verification date: 28/04/2010 15:33:02]
[AccurateRip ID: 00148e86-00cdc11f-a20a200d] found.
Pregap length 00:00:33.
[CTDB TOCID: pcqRY4ScJAqkf0Xd2GWyYGrNFFU-] found.
        [ CTDBID ] Status
        [63c6f835] (67/67) Has pregap length 00:00:00


Wouldn't it be better if cuetools returned something less strict, like:
"CTDB reported pregap length 00:00:00, No match, you may have different pressing"
or
"CTDB reported data track length 08:57:40, No match, you may have different pressing"
instead of
"Is an Enhanced CD, data track length 08:57:40, No match"

Or am just wrong & the strict way of displaying the information is simply due to the fact that it is the absolute truth & then something is wrong in my rips ...

The actual wording is so inquisitive that it make you think that your rip is bad. I know that there are actually holes in my understanding & that I need to test more, but I have the intuition that my rip might be OK (no datatrack, not the same pre-gap) & that CTDB is giving me useless information about a pressing that is not mine just because the CTDBID is the same for the various pressings.

How is this CTDBID calculated ? specially does it use datatrack & pre-gap to avoid clash ?
There is obviously something that I am missing somewhere in order to understand what information is wrong which is right.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #972 –
Quote from: Gregory S. Chudov on
Quote from: sonofdbn on
Exception: failed to autodetect read command

That means that your CD drive model is not supported by CUERipper at this time  What is your CD drive model?


The DVD/CD drive is a Samsung - it says "Super Writemaster" on the front. Windows properties says it's a TSSTcorp CDDVDW SH-S223C. Is there a list of supported drives somewhere?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #973 –
Maybe a bit late, but I just found the pregap 32, 33, 37 script: Thank you very much!!! 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #974 –
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself? If I set "audio output" to none in the image+cue mode and select "encode" for action, then nothing gets written to the output dir, except perhaps an accurip file.

The "correct filenames" action doesn't do this either. The "repair" custom script doesn't seem to do anything. The "Create cue sheet" action is disabled. The GUI of this otherwise fine program is rather confusing...