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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1825
Quote
CUETools 2.1.2 is out!
Please don't forget to update the version info under "Check for updates"
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1826
CUETools says it needs .NET Framework 2.0 (SP2) to run but what if I have .NET Framework 4 installed? Do I still need to install .NET Framework 2.0 SP2?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1827
No.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1828
Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1829
I've been encountering some situations in which I am unable to perform a repair on a defective rip. When the "repair" script is used, CUETools simply verifies the rip without proceeding with the repair although the log suggests that a repair is possible. This issue seems to affect those with discs with multiple entries in the database. Perhaps CUETools is "confused" by the various CTDB submissions and is unable to choose upon which disc to base its repair. Both the 2.1.2a and 2.1.4 versions exhibit this behavior. I was wondering if anyone else is experiencing this issue.

Here is an example of a disc for which a repair fails. I am attempting to perform a repair of the first track based on the 3 disc submissions (out of 4) in the database that I presume represent the "accurate" rip. As you can see, one of the 4 submissions appears to have some errors in the last track judging from the AccurateRip results. Is there a way for CUETools to select the most likely "proper" rip for repair?

Code: [Select]
[CUETools log; Date: 4/18/2012 11:23:32 PM; Version: 2.1.4]
[CTDB TOCID: r81jSzMBwJxxnkcsRBbGivrNHBA-] found.
[ CTDBID ] Status
[abc01ed8] (3/4) Differs in 4 samples @00:01:18
[8ac12682] (1/4) Differs in 9016 samples @00:01:18,55:48:31-55:48:39
Track | CTDB Status
 1  | (3/4) Differs in 4 samples @00:01:18, or (1/4) differs in 4 samples @00:01:18
 2  | (4/4) Accurately ripped
 3  | (4/4) Accurately ripped
 4  | (4/4) Accurately ripped
 5  | (4/4) Accurately ripped
 6  | (4/4) Accurately ripped
 7  | (4/4) Accurately ripped
 8  | (4/4) Accurately ripped
 9  | (4/4) Accurately ripped
 10  | (4/4) Accurately ripped
 11  | (3/4) Accurately ripped, or (1/4) differs in 9012 samples @22:55:02-22:55:10
[AccurateRip ID: 00102a71-0091571b-920d140b] found.
Track  [  CRC  |  V2  ] Status
 01 [9281f13f|74b2638a] (00+00/27) No match
 02 [67a65937|8db88f4d] (24+04/28) Accurately ripped
 03 [7bac25bf|47c0c20c] (24+04/28) Accurately ripped
 04 [14d9f48a|287e971f] (24+04/28) Accurately ripped
 05 [2ead58ec|4a108ee7] (24+04/28) Accurately ripped
 06 [a91bde9b|c5418916] (24+04/28) Accurately ripped
 07 [8ddc9a2e|cc601eee] (24+04/28) Accurately ripped
 08 [e154a216|f4bc5ba4] (24+04/28) Accurately ripped
 09 [d4ef942d|ffe2de14] (24+04/28) Accurately ripped
 10 [eb3faa48|ca00c112] (24+04/28) Accurately ripped
 11 [2f32dd9a|a68b7934] (21+04/25) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [4BD147E7] [71A732FA]  CRC32 
 01  100.0 [385E8A08] [4FB7DFE5]  
 02  100.0 [8602C32D] [5D708A63]  
 03  100.0 [993C8D56] [C97FAF90]  
 04  100.0 [B774CE8E] [0A6F3A8E]  
 05  97.8 [6F198A5C] [05DC654E]  
 06  99.2 [4E326893] [D23F9EE2]  
 07  100.0 [24FAA82B] [DE1E478C]  
 08  99.9 [65065D09] [90AB474E]  
 09  100.0 [38D4FA51] [C72683CD]  
 10  100.0 [CA6DC859] [E97ACD95]  
 11  100.0 [A4DE95CC] [197505F2]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1830
There is a known bug which i forgot to fix:
Repair function needs to display a window asking confirmation and presenting you with a choice of available repair targets.
CUETools disables interactive windows when processing in batch mode, for example if you are using drag'n'drop or multi-select file browser, or if you selected a folder.
Try to select the source file in single Folder browser mode instead.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1831
Yes! Your suggestion worked! Thank you, Gregory!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1832
Is there any plans on getting CUETools to check against the AR v2 database also or?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1833
It does check against the ARv2 database since v2.1.2 (except limited to zero offset only).
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1834
Is there any plans on getting CUETools to check against the AR v2 database also or?

It already does. The only thing that's missing is cross-pressing support, that is, it'll check the AR v2 database if and only if your disc is properly offset-corrected.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1835
It does check against the ARv2 database since v2.1.2 (except limited to zero offset only).


It already does. The only thing that's missing is cross-pressing support, that is, it'll check the AR v2 database if and only if your disc is properly offset-corrected.


Thnx for the info.

Cross-pressing support would be very nice 2 get added for sure.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1836
Is there a way to set where you want the ripped files from CUERipper? If it's possible so do i really wanna know how and if not so would it be a nice thing to get added.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1837
Quote
Is there a way to set where you want the ripped files from CUERipper? If it's possible so do i really wanna know how

Do you mean a destination directory?  If so, yes.  Just define it in the prompt under the track table.

I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1838
Now i see where to do it. It have to be done manually. No folder browsing option. Must be totally blind here

Thnx MrMonkey

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1839
I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.
You could do both with a single template: (but both DISCNUMBER and TOTALDISCS required on multiple discs)

C:\Rips\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1,\Disc %discnumber%,)[' ('%unique%')']\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1, '('Disc %discnumber%')',).cue

I've added %unique% so if you rip the same disc twice it will add (1) instead of overwriting.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1840
Is there any way to 'update' the CUE sheet to match the current tags of the associated FLAC files without re-encoding (similar to 'correct filenames'). Since ripping I have updated/corrected quite alot of the metadata contained within the audio files.

Regards,

Ben

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1841
I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.
You could do both with a single template: (but both DISCNUMBER and TOTALDISCS required on multiple discs)

C:\Rips\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1,\Disc %discnumber%,)[' ('%unique%')']\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1, '('Disc %discnumber%')',).cue

I've added %unique% so if you rip the same disc twice it will add (1) instead of overwriting.


That was a very useful 'command line' korth. Thnx a lot for that 1.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1842
Hi
CueTools is a great tool. Thanks for it
Just want CueTools to be even better.
I use now 2.1.4. Usually convert one big wav or flac file to tracks (flac files using libFlake) with separate cue.
I have a huge collections of CDs and use Logitech Media Server (LMS) with Squeezebox to listen and a tablet with android OS to navigate.
So proper tags are important for me and are used vastly by LMS to navigate, sort and so on.
For example I can click composer on a track and find which other releases of such artist I have in my collection.
I know my needs are rather not usual for most users specially with portable players.

1. A bug:
When there are less tracks in discogs database then in the image file, the "Select the best match" window shows tracks with empty track titles and the output files names are not correct.
They are like:
01 - %title%.flac
02 - %title%.flac
...
10 - %title%.flac

It happens when there are hidden track/tracks in CD and not described on the back cover/official listing and then some databases don't include these tracks in their listing, just sometimes it's mentioned in "Notes" that some tracks are hidden/untitled.
For example: Haujobb - Ninetynine (MET 113) has 10 tracks but only first 9 are in the listing on the cover and then in discogs
http://www.discogs.com/Haujobb-Ninetynine/release/16781
But in promo release it's described correctly with 10 tracks
http://www.discogs.com/Haujobb-Ninetynine/release/1670904

2. Could be better:
When there are many artists with the same name, discogs add a unique number in parenthesis to differentiate such artists.
For example Klute (Danish electro band) is Klute (2) in discogs:
http://www.discogs.com/artist/Klute+%282%29
Then these names are written it tags and in file/folder names with this number by CueTools. I think it should be removed.

Similar thing is with artist with "The" at the beginnig of name.
For example "The Cassandra Complex"
http://www.discogs.com/Cassandra-Complex-W.../release/308322
is written in discogs as "Cassandra Complex, The".
I think that "The" should be moved at the beginning of name: "The Cassandra Complex".
It could also apply to other articles but I haven't found

I know I can change it in "Select the best match" window

3. Some more tags:
CueTools gets already barcode number but writes it only in cue sheet (as CATALOG) but not in tags. What a pity
I use UPC tag and extract the barcode from discogs description using mp3Tag regular expressions.
Discogs provides some more tags:
- for tracks:
  • Written-By (could be written in COMPOSER and LYRICIST tag),
  • Music By (could be written in COMPOSER tag),
  • Lyrics By (could be written in LYRICIST tag),
  • Remix (could be written in REMIXEDBY tag)

These are tags which TagScanner uses when tagging from discogs.
There are sometimes more tags for tracks like vocals or featuring (for example when there are quest artists) and I add them to track artist besides standard track artist.
It could be nice to have them added by CueTools but I know not everyone likes this way...Maybe some option ?

- for release:
  • Format - mp3Tag writes it in MEDIATYPE tag
  • Discogs Release ID - mp3Tag writes it in DISCOGS_RELEASE_ID tag.
    For Musicbrainz could be MUSICBRAINZ_RELEASE_ID tag


4. Separate artists:
There are releases or just tracks where there are more than one artist in ALBUM ARTIST (for a release) or ARTIST (for a track) - I don't mean VARIOUS ARTIST.
For example: Deep Forest with Peter Gabriel – While The Earth Sleeps
http://www.discogs.com/Deep-Forest-With-Pe...release/1600968
"Deep Forest" and "Peter Gabriel" are different artists and they are linked separately in these discogs release.
It could be written in separate tags: two (in these case) ALBUM ARTIST tags for release and two ARTIST tags for such tracks.
Or it could be written in one tag with a separator. I use "; ". So for me it's ALBUM ARTIST="Deep Forest; Peter Gabriel" and for track 1 and 3 ARTIST="Deep Forest; Peter Gabriel".
But I'm afraid it's could be hardware/software depended to read such tags...

5. Tags mapping:
It could be a nice feature to be able to configure how to write some non standards information(fields) to tags.
For example fields like: labelno, releasecountry, release date (why isn't it releasedate as previous?  ), barcode...
As I know it's format depended (different for flac, mp3, ape) but my knowledge is poor...
So it could be a table:
field/tag | FLAC | MP3 | APE
field1    | tag1  |  ...  | ...
field2    | tag2  |  ...  | ...

In each cell (for a specified format and field) you can choose: <default>, <blank>, choose from a list of other tags or write your own custom tag name.
Where:
<default> - default CueTools tag
<blank> - field is not written to tag
But I know it's complex.

Once again thank you for a great piece of software.
It's not a criticism just want to present some my ideas to make a CueTools an ultimate tool.
You can use it or just forget it

Best regards
Roger

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1843
What happened to "whole album" check concept? I see that now it is just gives results per track, just like Accurip. I thought that that was not even possible.

What differences between CTDB and AR are left?

Is it still possible to have this in the new logs:

[CTDB TOCID: B95jzBQTLVkXdF9exkf4KxYAAwQ-] found.
        [ CTDBID ] Status
        [9af9f5f3] (304/304) Accurately ripped

I liked it, and I used it in my scripts.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1844
Is it still possible to have this in the new logs:

[CTDB TOCID: B95jzBQTLVkXdF9exkf4KxYAAwQ-] found.
        [ CTDBID ] Status
        [9af9f5f3] (304/304) Accurately ripped

I liked it, and I used it in my scripts.

CUETools 2.1.4: Advanced Settings -> Advanced -> CTDB -> Detailed log = True
CUERipper 2.1.4: Options -> CTDB -> Detailed log = True

Also, I've written a page on the new log here.
I'm going to start on 'settings' pages next.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1845
CueTools is a great tool. Thanks for it
Just want CueTools to be even better.
I use now 2.1.4. Usually convert one big wav or flac file to tracks (flac files using libFlake) with separate cue.
I have a huge collections of CDs and use Logitech Media Server (LMS) with Squeezebox to listen and a tablet with android OS to navigate.
So proper tags are important for me and are used vastly by LMS to navigate, sort and so on.


(I have added bold to referencing to TAGS, I hope this helps reading and not makes my post look like an annoying cheetah, LOL)

Interesting, detailed post. Just adding my thoughts about some things you mentioned. If you use FLAC files exclusively then all is OK for you, and by normal standards, I don't believe that WAV files are to have any kind of tagging data (though AIFF, Apple's version of WAV can). Personally, I use FLAC files as well, and I also embed CUE files, but I was thinking CATALOG was written? Maybe I am wrong, it's very possible. Maybe very likely, haha... but when comparing the tagging of FLAC files vs. using ID3 tags for MP3's, or Apple's "atom" format tagging of MP4 container files (M4A)... they're quite different. For FLAC files, I know this much...

There is a structure of about 8 parts complete that FLAC files are built using. The very first is a STREAM INFO header (please, no need to correct and be exact on that, I'm demonstrating only the concept that's important)... then we have 1-2 more... then we have a VORBIS COMMENT block, in which our tagging goes for the tracks. After that, we have a separate CUESHEET block, which holds the obvious... then an ART block (or can be several instances for front, back, extra covers)... finally, we have the actual stream of audio data block. I skipped a few that I do not recall off of the top of my head, but the important idea I'm making is that the VORBIS COMMENT, CUESHEET, and ARTWORK are all contained in separated "blocks". Unfortunately, I do not know what goes on inside of the VORBIS COMMENT block... what is allowed and what is not, etc. You may know this detail since it appears you have studied into things, as well.

We know in a typical "bare-bones" CUE sheet, we will have a few things:
REM GENRE
REM DATE
REM COMMENT
(usually EAC or the encoder will put their info here)
REM DISCID (CDDB database hash, 8 hexadecimal positions)
CATALOG (usually pulled from the CD-TEXT it most times matches the UPC for USA, or EAN for Europe; as you said: your BARCODE)
PERFORMER
TITLE
FILE
  TRACK...


I won't go further, this is just for skeleton outline. What I don't understand, Roger7... is why these first few items are so non-standard or in other words, they don't follow logical rules. For specifics:
Even though GENRE is technically only a REM (remark) line, it is embedded to file tags. Same is true of date/year. Comment? I think it's left out. DISCID is left out, I believe...  and you say that CATALOG is left out, as well... even though it is *not* a REM line, and seems (logically) as it should be included, right? But even still, REM's are selectively added, not as a standard/uniform practice.

Other info we have extra that is non-structure related are ISRC codes for each track, and sometimes we get FLAGS DCP for copy protection which are safely removed.

Are we leaving out DISCID because we have no standardized field for this? CATALOG I felt pretty sure is a standard field.

Just for further note, when I'm in the process of ripping new CD's I may add, also in the CUE file, I add even further non-standard things. Mine, I add these lines to the CUE file:

REM LABEL
REM LABELCAT


Eh, those are all I can recall off hand, but I believe this sh... whoops said sh1t accidentally!!! hahahah... this SHOULD map LABEL->PUBLISHER and as far as I know there is no field for internal catalog for the label. Can you or anyone let me know if there is such a field? To make specific, CATALOG is maybe 00934923848123 (imagine the 12 or 13 digits or whatever lol)... which I consider to be CATALOG/UPC/EAN/BARCODE... now we always have with the label an internal catalog number as well, you see this as maybe I'll make up "TN23" for Tooth & Nail Records, 23rd release is usually the standard. Another typical example is "392943-2". What do we do with this catalog? It is valid for internal use just as much as the barcode... as is the LABEL important. If I were to change this to REM PUBLISHER would it add the tag? I figure the answer is no. It would be nicest if for any entry we have here, we get the name mapped to the identically named tag... so if I put say... REM FOO BlahBlahBlah -- then it would write a tag named "FOO" with value of "BlahBlahBlah". In my perfect world, at least haha...

I want to ask this, do you or anyone else know if there is a way to embed any more information than GENRE, DATE, and... that's it I suppose? Are there ones like this that are real? (I've seen them but I have never known them to embed), according to tagging documents I have the correct tags are:

REM DISCNUMBER 1
REM TOTALDISCS 1
REM TOTALTRACKS 12
REM PUBLISHER Atlantic
or for two tokens, REM PUBLISHER "Atlantic Records"

Any way to embed any of these? Do I remove the REM, leave it, or it's just simply impossible to do without manual work? It's not huge work to add these, since I manually add artwork and sometimes certain tags for special types of music like remixes, multiple artists on a track, and this type of thing.

I need to know any secrets of the CUE file that I have not unlocked, LOL.

Oh, I'm sorry and my original point was that I know there is other threads discussing that FLAC uses ALBUMARTIST tag while ID3 uses ALBUM ARTIST tag -- but foobar2000's newest versions remedy this issue by making the correct tagging transparent to the users.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1846
Oh, I'm sorry to post again, but this would be lost in my post above and never seen. Just trying to be helpful!

This is just a friendly reminder to update the SUBJECT of the thread to reflect the true current version 2.1.4, right now it is showing incorrectly the old one.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1847
Sorry, i haven't got around to this yet.

UPD: tried to reproduce it, but couldn't. In theory this can only happen if takc.exe crashes on startup.

Indeed, you couldn't reproduce it because it's a bug in TAK, and not in CUETools. I feel very stupid for not having realized it previously. It is caused by the fact that TAK does not have support for Unicode file names.

Sorry for wasting your time.

By the way, I'm really diggin' the new AR logs. Way to go.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1848
Thanks again Korth.  I'm only up to page 9 so far!  Trying to take it all in rather than skim.

As I understand it, by doing at least 2 passes it is already doing test and copy.  The log file shows both CRCs anyway.

Hi everyone,

First of all, I'd like to thank Gregory S. Chudov for the great tools CUETools and CUERipper are. I'm using them with much satisfaction, especially because of the improved ripping speed compared to EAC, and also for the simplicity of their configuration ("best options" --if following HA lossless rip guide-- automatically chosen, etc.). I hope they'll become the preferred softwares when it comes to high quality encodes and verification.

Since the upgrade to version 2.1.4 though, I have a question concerning the "test and copy" feature: what is meant by
Please welcome, CUETools v2.1.4.

16.04.2012: CUETools 2.1.4:
* CUERipper: real test&copy mode
?
I've been looking at my log files from rips made with 2.1.2a: they display both Read and Copy CRCs. And then in 2.1.4, I've checked and then unchecked the new "Test and copy" box: it turned out that with the box checked, both CRC values were still present, but encoding took quite a lot more time; but when unchecked the log file only contained Copy CRCs.

Does that mean that on all my rips done with the previous version of CUERipper, no "test and copy" operation was performed, and the log was just mocking the option? (I'm sorry if it has already been discussed in this thread, I've browsed it up to page 30 but it's really vast and everything doesn't necessarily concern me...)

[off topic] Btw, would it be possible to create a dedicated topic in HA forums for CUETools/Ripper, so that questions could be addressed in separate threads and people wouldn't have to browse the whole one here? I assume it could reduce the number of duplicate questions...[/off topic]

Or did 2.1.2a always performed T&C without leaving the choice, and that's why you added a "real test and copy mode", so that it'd be a mode. But in that case, why ripping would take so longer with the new version? I remember reading here:
As I understand it, by doing at least 2 passes it is already doing test and copy. The log file shows both CRCs anyway.
So what does it mean?

Thanks again for your tools, I hope development will pursue the excellent work.

Best regards

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1849
CUERipper always does at least two passes in secure mode. If results from those two passes differ, or the drive reports C2 errors, it does more passes, and the error correction progress bar lights up. If the problem persists, it eventually marks suspicious positions in the log file. But it is not collecting separate CRCs for those passes, because some parts of a track can be read twice while other parts can be read many times.

So before version 2.1.4 it just printed the same CRC twice. It was pointed out to me that this is misleading, because some people actually like to compare CRCs with their own eyes, so 2.1.4 just prints one CRC unless you check 'Test & Copy', in which case it now collects two sets of CRCs by reading the whole CD twice, doing at least two passes each time, so every sector is read at least 4 times.

I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy), or if i expect problems ripping a certain CD and don't mind waiting a bit longer, i use Paranoid mode (which reads every sector at least 3 times). This is usually faster than test&copy in secure mode, but has a better chance of doing a perfect rip.

Unlike Paranoid mode, Test&Copy doesn't increase your chances of getting an accurate rip, so i guess the only reason it is so popular is that you can see two sets of CRCs with your own eyes and compare them yourself, instead of trusting the ripper to compare each bit of data from several passes and print out the suspicious positions.
CUETools 2.1.6