IPB

Welcome Guest ( Log In | Register )

103 Pages V  « < 92 93 94 95 96 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
Brian_OConner333
post Jul 6 2013, 17:17
Post #2326





Group: Members
Posts: 6
Joined: 3-July 13
Member No.: 108948



New version didn't fix my problem, still getting that message sad.gif
Go to the top of the page
+Quote Post
Fandango
post Jul 6 2013, 17:46
Post #2327





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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.

This post has been edited by Fandango: Jul 6 2013, 17:55
Go to the top of the page
+Quote Post
Wombat
post Jul 6 2013, 19:12
Post #2328





Group: Members
Posts: 1039
Joined: 7-October 01
Member No.: 235



Stil no option to prevent the CUE COMMENT written to the tag.
Go to the top of the page
+Quote Post
korth
post Jul 6 2013, 22:55
Post #2329





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



QUOTE (Fandango @ Jul 6 2013, 17:46) *
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
Go to the top of the page
+Quote Post
Fandango
post Jul 7 2013, 14:04
Post #2330





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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?
Go to the top of the page
+Quote Post
korth
post Jul 7 2013, 15:43
Post #2331





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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.

This post has been edited by korth: Jul 7 2013, 16:02


--------------------
korth
Go to the top of the page
+Quote Post
Eli
post Jul 8 2013, 01:06
Post #2332





Group: Members
Posts: 1056
Joined: 16-October 03
Member No.: 9337



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...


--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jul 8 2013, 01:08
Post #2333





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Can you play around with tags on those files? For example, removing CDTOC tags, etc.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jul 8 2013, 02:35
Post #2334





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (Brian_OConner333 @ Jul 6 2013, 12:17) *
New version didn't fix my problem, still getting that message sad.gif

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.4
Go to the top of the page
+Quote Post
Brian_OConner333
post Jul 8 2013, 09:59
Post #2335





Group: Members
Posts: 6
Joined: 3-July 13
Member No.: 108948



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.

This post has been edited by Brian_OConner333: Jul 8 2013, 10:26
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jul 8 2013, 12:48
Post #2336





Group: Developer
Posts: 699
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.4
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 8 2013, 13:21
Post #2337





Group: Members
Posts: 493
Joined: 11-March 07
Member No.: 41384



My older PC with a 8600m GT exits with the same error message, so that's probably it.
Go to the top of the page
+Quote Post
mjb2006
post Jul 9 2013, 20:19
Post #2338





Group: Members
Posts: 811
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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.
Go to the top of the page
+Quote Post
Pidgeon
post Jul 14 2013, 18:36
Post #2339





Group: Members
Posts: 29
Joined: 27-April 10
Member No.: 80211



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

This post has been edited by Pidgeon: Jul 14 2013, 18:38
Go to the top of the page
+Quote Post
Goratrix
post Jul 14 2013, 19:05
Post #2340





Group: Members
Posts: 125
Joined: 5-August 08
Member No.: 56722



How many drives did you use to make those rips? rolleyes.gif

(Hint: CUETools is meant to be a tool for veryfing your own rips wink.gif and that should be its development focus)
Go to the top of the page
+Quote Post
greynol
post Jul 14 2013, 19:07
Post #2341





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



If you're that fucking anal about your music, buy the CD.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
Pidgeon
post Jul 14 2013, 22:43
Post #2342





Group: Members
Posts: 29
Joined: 27-April 10
Member No.: 80211



@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!

This post has been edited by Pidgeon: Jul 14 2013, 22:48
Go to the top of the page
+Quote Post
greynol
post Jul 14 2013, 22:59
Post #2343





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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?


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
Pidgeon
post Jul 14 2013, 23:15
Post #2344





Group: Members
Posts: 29
Joined: 27-April 10
Member No.: 80211



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.

This post has been edited by Pidgeon: Jul 14 2013, 23:26
Go to the top of the page
+Quote Post
greynol
post Jul 15 2013, 01:46
Post #2345





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 15 2013, 11:35
Post #2346





Group: Members
Posts: 493
Joined: 11-March 07
Member No.: 41384



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.
Go to the top of the page
+Quote Post
Pidgeon
post Jul 15 2013, 14:00
Post #2347





Group: Members
Posts: 29
Joined: 27-April 10
Member No.: 80211



QUOTE (greynol @ Jul 15 2013, 01:46) *
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.

QUOTE (ChronoSphere @ Jul 15 2013, 11:35) *
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?

This post has been edited by Pidgeon: Jul 15 2013, 14:33
Go to the top of the page
+Quote Post
ChronoSphere
post Jul 15 2013, 14:10
Post #2348





Group: Members
Posts: 493
Joined: 11-March 07
Member No.: 41384



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 =/

QUOTE (Pidgeon @ Jul 15 2013, 15:00) *
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.

This post has been edited by ChronoSphere: Jul 15 2013, 14:20
Go to the top of the page
+Quote Post
korth
post Jul 15 2013, 14:26
Post #2349





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



QUOTE (Pidgeon @ Jul 15 2013, 14:00) *
So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database

See Post #444, #1078 & #1500. I might be able to find more but you can search for yourself.


--------------------
korth
Go to the top of the page
+Quote Post
greynol
post Jul 15 2013, 14:43
Post #2350





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (greynol @ Jul 14 2013, 17:46) *
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.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post

103 Pages V  « < 92 93 94 95 96 > » 
Reply to this topicStart new topic
3 User(s) are reading this topic (3 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st September 2014 - 17:23