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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2325
Here's an idea for a possible feature I want to share. It comes from an experience I recently encountered with a defective reissue.

The problematic CD has audible errors which must have been introduced during mastering it in the CD fab or maybe because a defective original pressing was used as a source or something like that. Yes, there exists an original pressing which is almost identical, apart from an offset and those corrupted sectors. And my reissue is present in both AR and CTDB and it verified fine, so these exact same defects must be present in other people's CDs, too.

Since the differences are only minimal (on most tracks affected) and may have been covered by Cue Tools' error correction, I'm wondering why not let the user mask a certain pressing as a different one if he likes, and let CUE Tools "repair" it as if it were that different pressing.

I tried to trick CUE Tools into believing the rip was the original pressing of which repair information is present in the CTDB by offsetting the audio. But I must have missed something, because CT still recognised it being the new pressing, just with an offset... maybe you can tell me how exactly does CUE Tools determine which pressing a set of files is, Gregory?

Of course, just like one can override the offset it would be really neat to override the pressing identifaction at will so that during verification the log is written as if it was another pressing and during repair the rip is repaired with the other set of recovery data.

With the "defective" CD what I ultimately did was buy an old used original copy and ripped that one. Bonus was that I could finally compare both of their audio tracks, it turns out that on the first track apart from an audible glitch there are even a few samples missing right after the glitch, cut out, so that both tracks would be out of sync for half a minute, then the same number of samples is reinserted in the audio stream, but it's simply a duplicate of the samples that come right before the insertion. I wonder if CUE Tools would be able to repair such a complex defect.

Anyway with such a feature, people can in rare cases where they have bought a reissue with minor mastering errors which is not repairable transform it into a different pressing.

Oh, and while I'm at it I have another idea:

Why not introduce a repair log? Something that gives some clues about which samples have been repaired and how the damaged samples have looked like (null samples, etc...) and maybe some other stuff.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2326
Stil no option to prevent the CUE COMMENT written to the tag.
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 #2327
I tried to trick CUE Tools into believing the rip was the original pressing of which repair information is present in the CTDB by offsetting the audio. But I must have missed something, because CT still recognised it being the new pressing, just with an offset... maybe you can tell me how exactly does CUE Tools determine which pressing a set of files is, Gregory?

With AccurateRip, 'alternate pressing' usually means audio CDs that have the same TOC (all tracks start and end at the same positions) and have identical data throughout the CD but at a different offset (see wiki). CTDB uses an Offset-finding checksum, a small (16-byte) recovery record for a set of samples throughout the CD, which allows detection of the offset difference between the rip in database and your rip, even if your rip contains some errors (from this wiki). Discs with the same TOC would fall under the same CTDB TOCID (any HTOA (disc pregap) and CD-Extra data track info is excluded from the TOCID calculation and is stored separately in the database). Discs under that TOCID with the same data (same CRC32 excluding some samples at the start and end of the disc to allow for offsets) fall under the same CTDBID. I'm paraphrasing most of this from the wiki. So if there are no differences in data between the pressings (except the data offset) and all tracks start and end at the same positions, both would have the same TOCID and CTDBID in the CTDB.

So if your 'defective CD' is an alternate pressing of the 'old used original copy CD' then both will fall under the same TOCID (which can be seen if you enable the Detailed log in CUETools). Each disc would fall under a different CTDBID due to the glitch but the rest of the disc should match. If the remaining differences are small enough to be repaired by the recovery record under the 'old used original copy CD' CTDBID you should see 'Differs in xxx samples' listed for that CTDBID when you verify the 'defective CD'. If it says 'No match' then too many samples differ to use the recovery record and you're out of luck.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2328
Dang, I didn't realize CUE Tools has a wiki! I will check that information there against the two CDs and see how great the differences are.

So you are saying if the two pressings are close enough to be repaired then they would have been identified as the same pressing anyway by CUE Tools? Or did I not understand it correctly?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2329
Yes, identified as the same in the CUETools database (CTDB) with possible errors. However, if both the 'original' and 'glitched' discs are in the database with good quality under their respective CTDBIDs, then verifying one disc could show a match for one CTDBID and 'Differs in' for the other. Verifying the other disc would give similar results but flipping CTDBIDs.

Your rip log and AccurateRip can help to identify your rip so you don't repair when it isn't necessary.

Edit: Changed confidence to quality. A good quality rip (no errors) is normally needed for a recovery record to be in the database.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2330
With the latest CueTools 2.1.5 I am still having a lot of problems with the following scenario:

Rip CD with some errors (ripping w/ dBpoweramp)
Repair with CueTools
Copy only the repaired tracks back to the original album
- fix the padding on disc and track numbers (typically use foobar for this)
Attempt to re-verify with CueTools.

The last step is where things go wrong. Before CT was consistently seeing only the first 2 tracks in an album folder in the above scenario. Now it doesn't see any audio files in the folder...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2331
Can you play around with tags on those files? For example, removing CDTOC tags, etc.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2332
New version didn't fix my problem, still getting that message

Could you please try the command-line FLACCL encoder? For example like this:
CUETools.FLACCL.cmd.exe somefile.wav -o nul

It will fail the same way, but it should show a more detailed error message that can help me identify the problem.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2333
I'm getting this in commandline

I guess. that there may be a problem with my GPU, because few days ago i found out that I can't play games anymore (it simply freezes). So if nobody with 9800GT or lower has the same problem, than the problem is in my GPU.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2334
Thanks. I don't think that your GPU is the problem, i just used couple of features that are probably not supported by it. I thought they were.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2335
My older PC with a 8600m GT exits with the same error message, so that's probably it.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2336
I'm posting on behalf of a friend who says CUERipper 2.1.5 (current) crashed on him (Exception dialog) when ripping the last track of a particular 74-minute bootleg CD. After the exception, the drive was no longer recognized by the OS, but it came back after a reboot.

Exception: Error reading CD: IoctlFailed
Drive: HL-DT-ST DVD-ROM GDRH20N 0L02
OS: Win7 64-bit

That's about all I have to go on. A bit of Googling reveals that the DVD-R version of this drive is known to have the same kind of problem on the last track when burning, but my friend's drive is read-only, and I don't see anything about problems when reading. Let me know if I need to have him try anything different or gather more info.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2337
Hello, I've been using CUETools for a couple of years, and now I'm using the 2.1.4 version.

I noticed that CUETools looks for the log file of a given rip, when I want to verify it through accuraterip, asking me to select it.

Some log files have been produced by ripping a CD with a read offset equal to zero (or a wrong non-zero one in rare cases), so everytime I have to look to the accuraterip drive offset page to manually find the read offset of the drive used in the ripping process.

My question is, would it be possible to add a function that, when someone wants to verify a rip, does the following?:

1) it searches for the log
2) it ask the user to select the log
3) it identifies the drive used
4) it looks in the accuraterip drive offset database
5) it asks the user if he wish to apply the correct offset
6) it eventually sets the offset, if the user has decided to do so

I wanted to suggest this because in my opinion it would be a great time saver.

This would be nice for the following modes of CUETools:
- Encode
- Verify

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2338
How many drives did you use to make those rips? 

(Hint: CUETools is meant to be a tool for veryfing your own rips  and that should be its development focus)


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2340
@greynol

Fortunately I've bought enough CDs to make my own rips and proper considerations. On the other hand, it would be extremely difficult for me to follow your fine suggestion in some special cases of mine, but I appreciate your interest, anyway.

@Goratrix

Here is my suggestion: if someone is unfamilar with EAC and uses a wrong read offset during the ripping process, I think that it would be a good idea for CUETools to detect the log file (it already does that), to analyze the read offset used, and to finally provide the correct read offset to the user. I think it could be done by using some regular expressions / parsing on the log file, and querying the accuraterip read offset database (like it happens on EAC + AccurateRip).

A strong point of CUERipper should be that it greatly simplifies the process of ripping a CD (skipping the long EAC configuration), so CUETools could do something similar, by suggesting the inexperienced user the correct value for the offset, before verifying or encoding the audio tracks through CUETools, by analyzing the already existing log file.

It would be interesting to hear Gregory impressions, to verify it technical feasibility. In my humble opinion, it would be a feature appreciated by many.

In any cases, I'm anxious to try the new 2.1.5 version once it gets stable, I'm sure that many improvements will be made!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2341
The reference used by EAC and adopted by AccurateRip is hardly as sacrosanct as you appear to believe it to be.

If I use something different, who are you to say that I am not correct in doing so?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2342
I suppose you are referring to the read offset - drive association?

In that case, no one could know the answer, like you're correctly stating. Thus, the probability to have some mismatches, is unfortunately different than zero, so it could probably happens.

But statistically, there is a huge difference. Let's consider a real case: I analyzed more than 500 CD with CUETools, some with correct offset and some not, but in each case there haven't been any mismatch, once I set the correct drive read offset.

You are right, there could be some special cases of mismatch... but even 1% of the total cases, in my opinion is negligible.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2343
That's not at all what I was getting at, but whatever. Gregory Chudov knows what I'm talking about which is all that matters. If he implements your suggestion I will still hold you responsible for any misinformation that may result.

So that you may know, none of the entries to which you are referring as having the "correct offset" actually have the correct offset because the reference wasn't properly determined.

Don't take this as an endorsement for the true offset, rather I'm poking fun at those who think their ill-gotten music is somehow better if it is calibrated to an arbitrary reference.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2344
I don't even understand what Pidgeon wants to be honest. Even if the cd was ripped with a wrong offset, cuetools will still be able to verify if it was ripped correctly (offsetted by xxx). And from what I remember, Gregory said that using the "fix offset" (so that no offset has to be applied when verifying) shouldn't be used unless the offset is horribly wrong, e.g. audibly wrong transition between tracks etc.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2345
That's not at all what I was getting at, but whatever. Gregory Chudov knows what I'm talking about which is all that matters. If he implements your suggestion I will still hold you responsible for any misinformation that may result.

So that you may know, none of the entries to which you are referring as having the "correct offset" actually have the correct offset because the reference wasn't properly determined.

Don't take this as an endorsement for the true offset, rather I'm poking fun at those who think their ill-gotten music is somehow better if it is calibrated to an arbitrary reference.


Rather I was laughing at the "If he implements your suggestion I will still hold you responsible for any misinformation that may result" part. Do you think that I could be the cause of the world to collapse? Or this is what have been prophesied by the Mayan civilization? Well, some of the ideas you have might sounds right, but you are taking this way too seriously, and I don't need a personal judge who tell me of which things I'm responsible and which not, I think to be old enough to take my own responsibilities. After having clarified this, remember that everything started from a simple suggestion. Good or bad it was, this yet has to be seen.

Then, again, you are contradicting yourself: you are stating that Gregory knows what you are talking about about, and this is all that matters, which I think is great because he's the developer of CUETools, and not me or you. Afterwards, you state that I would be responsible if he implements my suggestion. But you just made a fine paradox, how could he implements my (wrong?) suggestion if he would know your (right?) reasons? We have two options:
a) Gregory doesn't know what you're talking about (but you suggested that this is not the case).
b) You think that Gregory could implement my suggestion, and its consequences "concern" you. I used the term "concern" because by your aggressive attitude, it seems that the consequences of my suggestion would be scaring for whatever reason, but I repeat mine was only is a simple suggestion for an already great software, I don't want to scare anyone.

You finally stated:
"Gregory Chudov knows what I'm talking about which is all that matters."
So I ask you with humility to enlighten me and the other users about the possible (technical) consequences that my simple suggestion could lead to, so that we could happily learn something about it.

Regarding the "ill-gotten music", this is your own assumption: you have no power to judge if, when, why or how I should own the music of my library. You don't know the story behind it, and you'll never be. Thus, please keep those unnecessary and accusatory assumptions for yourself.

Gregory said that using the "fix offset" (so that no offset has to be applied when verifying) shouldn't be used unless the offset is horribly wrong, e.g. audibly wrong transition between tracks etc.


This is interesting, is there a particular reason for that? Anyway, I suppose you are talking about the "encoding" process, where you can decide if to fix the offset or not. So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database and calculating the CRC for each track. In that case, in my opinion it would be a nice addition to know the correct drive read offset before starting the process, obtainable if the log file reports the drive used for the audio extraction. For what I know, by doing that, there would be problems only in the following cases:
- I rip a CD, then I manually modify the resulting log by changing the name of the drive I used in the ripping process.
- I rip a CD, then I grab a different log elsewhere, replacing the original one.
In these cases, CUETools would report a wrong read offset. Statistically, this won't likely happen, and anyway which are the reasons why someone would want to do so?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2346
d125q suggested using tak_deco_lib.dll instead of piping the decode output of takc here, to work around TAK's inability to handle unicode paths/filenames. Any chance of this happening?

edit: also, can we have an option to use a temporary file for encoding similar how foobar2000 does it? It creates a random ASCII named .wav first, which is then passed to the encoder, then renames the output file correctly once the conversion is finished. Again, a workaround for TAK's unicode problems =/

This is interesting, is there a particular reason for that?
From what I remember, a simple "never touch a running system". Maybe something might go wrong when fixing the offset, so it's reserved for cases where something already gone wrong. A "wrong" offset rarely matters anyway, so as long as CTDB/AR says it could match the rip, it's accurate.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2347
So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database

See Post [a href='index.php?act=findpost&pid=642349']#444[/a], [a href='index.php?act=findpost&pid=711430']#1078[/a] & [a href='index.php?act=findpost&pid=765329']#1500[/a]. I might be able to find more but you can search for yourself.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2348
If he implements your suggestion I will still hold you responsible for any misinformation that may result.

I've given this gentleman too much credit while not giving enough credit to Gregory.  My apologies.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2349
So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database

See Post [a href='index.php?act=findpost&pid=642349']#444[/a], [a href='index.php?act=findpost&pid=711430']#1078[/a] & [a href='index.php?act=findpost&pid=765329']#1500[/a]. I might be able to find more but you can search for yourself.


Yours is a truly informative post, I'm thankful to you. I'll surely give those post a thorough reading!

I'll wait for Gregory impressions, as I'm curious to hear what the developer thinks about my suggestion, in particular regarding the read offset identification before the beginning of the "verify" process. If he finds it to be an uninteresting thing to add, great, if he finds it to be a good idea, great! In any case, I'll keep using this great software like I did in the previous years, and I'll continue to spread the word about it!