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 1905101 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 #600 –
Hairston:
I would be curious about "the reason for", I must have missed them. It is not added information, it is added MISS-information. This only shows that even the high & mighty Gregory can make misstake & furthermore with good intention. The real shadow emperor is lord  Spoon.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #601 –
Quote
I rip without correcting offset & then check with cuetools because I want a cuetools log.


If you just ripped with the right offset and do a verify, you would be wasting less time.
A verify is much quicker than a verify and offset fix and gives a log too.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #602 –
Tigerman:
You're right.
My problem with speed is more about drive hanging forever trying to rip a damaged CD than pure CPU speed.

As I use flac -4 (significantly faster then -5) & will soon (can't wait for Q1 2010) have a nehalem clarkdale Core i3 530 (or Pentium G6950 depending on mobo price), CPU speed will not be a problem anymore.

I may switch too flac -1 if this is still not fast enough to my taste (Edit:doubtfull). Accuraterip as affected my flac setting too, I use -4 over -5 for the decoding speed gain. In fact Accuraterip has changed my audio world in many ways.

I agree my method is actually a bit painfull with my athlon/barton 3000+. I am already a step ahead & do as if I already had my clarkdale

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #603 –
i'm new to the forums i have come across a problem after using the latest version 2.04a. before trying out the latest version i was using 1.03 with no problems at all. i am running the 64 version as i am using vista home premium64.

i started the program and loaded a cue file, verified the music file and noticed the offset was wrong, i decided to encode and veryfy in a default location only to find no matter what lossless audio output and no matter if i am encoding to simgle or tracks only one audio file is created and always with the name '%tracknumber%. %title%'.

i tried firing up cuetools 1.03 which i had been using hours before with no problem and to my suprise that started encoding the files the same as above.

just wondering if anyone knows what has happened due to me using the latest version and how i can solve the problem, until i find a fix it is impossible to encode files propery using any of the previous versions of cuetools.

thank you

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #604 –
Quote from: sauvage78 on
Hairston:
I would be curious about "the reason for", I must have missed them. It is not added information, it is added MISS-information. This only shows that even the high & mighty Gregory can make misstake & furthermore with good intention. The real shadow emperor is lord  Spoon.

I don't know if I would call it misinformation, it is just "other" information. Showing this info doesn't make your rips any less accurate to someone who knows what it means.

For those people who don't understand the concepts of "pressings" as it relates to the AccurateRip DB should stick to the non-verbose log. I can't speak for the rest of us, but I don't mind seeing it in the logs.

We don't need to debate this any further, I'm just stating my opinion.

Keep up the good work!

I love the new feature of checking a directory of music files against the AR database without having to create a CUE sheet first. What a great idea!

I have a question though, I see in this new version there is no checkbox to turn off automatic offset fixing like in the other version. Or does it only automatically fix offsets when you are doing a batch? I guess my concern is that I really don't want it fixing offsets automatically on my encodes unless I specifically tell it to with a specified offset of my choice (not one automatically selected for me by CUETools).

This is another question that may have already been answered here and I apologize if it has, I am short on time, but is it possible to tell the new version to look in an alternate location to put its option files? As of right now I'd like to still use v1.9.5 for the time being and using v2.0.4a overwrites these files with its own settings and munges up v1.9.5 when I switch back.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #605 –
found out the solution to my problem...had to delete the settings file...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #606 –
Quote from: sauvage78 on
Tigerman:
You're right.
My problem with speed is more about drive hanging forever trying to rip a damaged CD than pure CPU speed.

As I use flac -4 (significantly faster then -5) & will soon (can't wait for Q1 2010) have a nehalem clarkdale Core i3 530 (or Pentium G6950 depending on mobo price), CPU speed will not be a problem anymore.

I may switch too flac -1 if this is still not fast enough to my taste (Edit:doubtfull). Accuraterip as affected my flac setting too, I use -4 over -5 for the decoding speed gain. In fact Accuraterip has changed my audio world in many ways.

I agree my method is actually a bit painfull with my athlon/barton 3000+. I am already a step ahead & do as if I already had my clarkdale


I wasn't talking about the secure vs burst.
I just pointed out that setting the right offset would save tons of time reencoding.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #607 –
It's true but you cannot be sure your pressing is the most popular in database, so it's random anyway.
But I agree if it happens that my pressing is the most popular in database then you're right, it's faster.
I'll set my offset correctly to save some watts  Fixing offset is a eco-responsible, after all these years I found a use for offsets !!!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #608 –
Quote from: sauvage78 on
It's true but you cannot be sure your pressing is the most popular in database, so it's random anyway.
But I agree if it happens that my pressing is the most popular in database then you're right, it's faster.
I'll set my offset correctly to save some watts

Are you really trying to tell me that you correct the offset to the most popular one?
That's imho a complete waste of time. You're only moving a few samples.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #609 –
Yes, but I am tired of explaining all the reasons why I am doing this  lol (It's bedtime here, sorry)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #610 –
Quote from: Hairston on
I have a question though, I see in this new version there is no checkbox to turn off automatic offset fixing like in the other version. Or does it only automatically fix offsets when you are doing a batch? I guess my concern is that I really don't want it fixing offsets automatically on my encodes unless I specifically tell it to with a specified offset of my choice (not one automatically selected for me by CUETools).

This is another question that may have already been answered here and I apologize if it has, I am short on time, but is it possible to tell the new version to look in an alternate location to put its option files? As of right now I'd like to still use v1.9.5 for the time being and using v2.0.4a overwrites these files with its own settings and munges up v1.9.5 when I switch back.

I figured both of these out on my own. It just wasn't obvious at first glance with the new UI.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #611 –
i think i'll just make some reinforcements to a couple of statements written in this post recently (you guys have been busy.. 20 something new posts since i last checked!) i don't really expect a response to this except for the last one, i'm just throwing some last thoughts out on this, cause i agree the topic is starting to become stale.

1- a real-life example to demonstrate accurate rips showing as wrong offset: i am going through the process of re-ripping my cd collection as single WAV+CUE, as my original rips were done multiple WAV+non-compliant cue. i know i could just rejoin, but this is easier for me, plus i can make these rips with new confidence that i have obtained by reading the board here. so -- after ripping some 40 CD's so far, i have gotten 39 perfect matches (minimum of more than 2 matches). just for extra paranoia i use secure rip + test&copy (overkill, some would say... it's just a matter of time and resources to make this personal opinion). still takes only a few minutes to rip a CD. i have 1 CD that has no matches. actually, two. this is a perfect example of why "no accuraterip matches" does not mean the rip is WRONG. the actual CD was "The Agony Scene - The Agony Scene". it had two matches, but was -17 and -685 offset from my rip. now, after ripping 39 other CD's with perfect results, and i do this rip, which has matching test+copy CRC's, i can say this rip is CORRECT by simple logic. it is just simply a third pressing of this cd that no one has ripped/submitted yet. besides, the other two matches were only 2 each... making for only 4 total matches on this disc, PERIOD. this demonstrates and (mostly) proves that just because your rip has no matches, it doesn't mean you need to correct the offset. as sauvage said, i believe... this would only to give you the "warm and fuzzies" that you're at least matching up with others. (how do you know those other rips were not bad rips to begin with, and yours is actually the correct one? you can't!) with an accuracy of of only 2 and 2 on the other "pressings", you could theoretically have two people that have ripped the same disc twice, wrong.


2- the end-all, be-all i think when talking about 'features' is to make them OPTIONS and not hard features. this could complicate things if you give people too much choice as we mentioned before, but ultimately, it's a way of making both crowds happy... they can enable or disable the feature... hence why a lot of times you see programs call it "PREFERENCES", and giving the end-user the power to choose the way/format/action they prefer. i think this is the answer to feature inclusion rather than arguing for or against.

3- does it really matter if your rip comes back as "no matches" or shows matches with different offsets if you know you ripped yours correctly, with the correct offset, etc... or like in my situation where i have 39 match record so far... i can say quite safely that my settings are configured right. that 1 cd that came back with no matches... the only reason i could should care that it doesn't match to something in the DB is if i were to post to the public, and them deem it as a bad rip! i know i did the rip, i know it's solid... case closed. i don't put it up on torrent or newsgroups or these things like "dirty pirate" lol... (gets me every time! i love the nickname!)

4- i can think of 1 situation where correcting offset *is* a viable and useful thing to do, and this is the case when CD's are ripped with 0 offsets. i know that one time, years back, i had just re-installed my OS and re-setup my EAC. i forgot to put in my cd burner's offset (this was before accuraterip came with EAC)... i ripped the CD with the incorrect offset of 0. i know now that particular drive's offset was +46. now i have the option (if the disc was lost or damaged or i didnt want to re-rip), i could "fix offset" and apply the correct offset to the audio rip (hopefully and probably replacing nothing but original silence/null samples). this is the useful case, when you KNOW the wrong settings were used... most often by you seeing in the log that drive offset is 0. haha as sauvage puts it "dirty pirates" (still makes me laugh every time i see this phrase) may download a rip, see the person who ripped it had no idea or care what accurate ripping was, and ripped it without making any drive offset correction, etc. then you run it through CUETools, or TripleFLAC or what have you... and you see there is only other 1 pressing with say... 57 matches at an offset of +72. "dirty pirate" could correct this by using fix offset +72, and feel better that the rip is now matching the rest.

5- sauvage, how long does it take you to rip a cd in secure mode/compress with -8 in flac/encode in lame --preset -extreme (slow, high quality)? i am just curious as it must be slow enough for you to trade time vs. disc space. just for reference, my rip time for an average CD in secure mode, test&copy is around 10 minutes. to encode that WAV file into FLAC using "-8 -v" took approximately 1 minute, 40 seconds on a 44 minute CD -- and this is with several programs running too. you make me curious as to how long it would take using burst mode in EAC or a lower compression setting in FLAC. and my computer isn't really "great" by standards, it's a Core 2 Duo 2.4ghz. but just *personally* i *prefer* to use highest compression, highest chance of a quality rip.. even if it takes more time. you seem to be the opposite (that is, with compression at least).



makes me wonder if i am wasting time doing this. if i can test and find that i consistently get the same results in burst mode, and find i never get test/copy mismatches... then yes... with presence of cuetools/accuraterip, i can still be confident i did a good rip, regardless of settings used. i may consider this.


one CD i find difficult to rip is TOOL - 10,000 days. there must be some sort of copy protection or something on this cd, as about halfway through the disc, it gets SUPER slow (would take like an hour or more to rip the cd fully), and i get all kinds of sync errors and re-reads over and over. the CD surface is pristine... not a single scratch, fingerprint, NOTHING. has anyone else experienced this with this particular CD if you have ripped it? i wonder if the pressing i got was bad or there is a bad part physically on the CD when created at the factory or what... or is this as said, some copy protection mechanism. i wonder. i will search the forums, see what i find.

[edit]: i did find some posts about it... some concerns mentioning some (or all?) copies were manufactured by SONY BMG MUSIC, which mine is... and that whole rootkit/copy protection fiasco. i think that was around the same time? it is the original CD bought in a retail store in the US. i'll try and find out what's going on and report back.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #612 –
People are really starting to annoy me with their "correct offset", there is no absolute correct offset. We should use something like "adjust" offset instead of "fix" or "correct" offset. I never said that having a rip with "no match" according to target offset was a mistake, I only said that, to me, it was useless spam that I could remove by "adjusting offset" to the most popular in database because I don't care about burning.
It's either you care about having an absolute exact copy of the CD you ripped in order to re-burn it or you don't care about it & offset is useless for you.

As Spoon said "a match is a match", you don't need match on your own pressing offset to know that your CD is accurate. You need a match on all tracks within the same offset no matter the offset.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #613 –
All this offsets talks is making me paranoid...
Let's say, I know that this disc came from a drive with no offset correction (0): (log shortened, the results for the other tracks are the same)
Code: [Select]
Track    [ CRC    ] Status
 24    [3ca99ed1] (00/18) No matches
Offsetted by -658:
 24    [d1259d71] (09/18) Accurately ripped as in pressing(s) #1
Offsetted by 6:
 24    [f2f1a1f1] (07/18) Accurately ripped as in pressing(s) #2
Offsetted by 2244:
 24    [89de2f91] (02/18) Accurately ripped as in pressing(s) #3

Can I say "I have a perfect rip, now I can burn it on a archival DVD so it will last forever"?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #614 –
buddhabar:
I cannot answer because I don't know what "perfect" means for you: it depends on if you want perfect audio data backup or a perfect CD architecture backup. Offset has nothing to do with audio data quality as long as gaplessness is not broken & samples from beginning & end are not cut off. Then for the same "perfect" audio data there is several "perfect" CD architecture, with only some samples of silence shifting within the margin of the gap lenght in sample.

If it where not silence but real audio data like some people are suggesting then accuraterip couldn't find matching CRC between pressings. This is how I understund Accuraterip, now it seems many people disagree with me but none has provided any real life proof of their claims. I may be wrong afterall, I dunno.

To be short according to me yes your backup is "perfect" no matter if the offset is 0 or adjusted by -658, 6 or 2244.

PS: You cannot judge accuracy of a full CD with a single track, it may sound stupid but I prefer add it...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #615 –
@sauvage78

Why don't you start your own thread for this discussion. You are filling up the CUETools thread with ranting that has nothing to do with the functioning of CUETools. The thread is long enough for people to sift through to fine info on CUETools.
Glass half full!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #616 –
This is not my discussion, it all started by answering question asked here.

I didn't ask anything to anybody & I don't need anyone to tell me what to do with my music.

I answered the questions to the best of my knowledge, now if people are not pleased by what they hear & want to fake there mind thinking that they have a "perfect rip" because they use a "perfect offset", it's their problem.

Now I have the feeling that I am walking-on-the-head & that the-world-is-reversed with this thread ... because it's people who think that their rips are "perfect" because they use "perfect offset" that are trying to teach me that I am a moron who think that I will make my own rip "better" by adjusting offset to the most popular in database, when the truth is that personnaly I don't give damn about offset while on the contrary they care a lot about their "perfect offset".

You think adjusting offset can break gaplessness, OK, prove it. Personnaly I tryed & I couldn't prove it.
Indeed adjusting offset randomly can break gaplessness but not between two matching accuraterip because you stay within the boundary of gaps (silence samples between song). If I am wrong, then teach me.

Edit: It seems people are misslead because CRC with different offset/pressing are different in the logs, as far as I understund they are different because they include silent sample at different place, but the CRC without silence is the same (but not displayed because it's useless spam) which mean the data is the same no matter how you fix offset.

I already asked about a separate threads, one for cuetools bugs & one for accuraterip & logs, I wasn't heard.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #617 –
Quote from: sauvage78 on
I recall I made my own test about gaplessness with an Alice in Chains CD & I didn't damage my gaplessness, the CRC of splitted songs with & without correcting offset was the same. I double checked the split stop/start point in audacity. Sorry I didn't post my result at time. I may be wrong & maybe my test was not enough & I ended with a special case. I don't know.

Shame, it would've been nice to read that.

Quote from: sauvage78 on
The discussion about this setting is interesting when it deals about if it can or not damage gaplessness

I think this is one other thing which made us misunderstand each others. I've not commented on this at all.. and what I understand, nor have Gregory and Greynol. The harmfulness I wrote was the start or ending cuts of samples of an album, not track. Maybe this technical talk is like a Boeing 747 to me, goes waaayy over my head.

Quote from: sauvage78 on
I don't intend to burn my rip, maybe you intend to burn yours, that's maybe why we have a different point of view.

Spot on! I didn't know that you don't care about the "identical" backup copy of your albums. I'm not burning my rips.. yet.. hopefully never have to resort to that.. but it's good to have an identical copy backed up.

Quote from: sauvage78 on
I rip without correcting offset & then check with cuetools because I want a cuetools log.

This also explains better what you're doing. You don't want EAC log at all. I think I do now understand what you're doing.

Quote from: sauvage78 on
It will only lead me to shut my mouth ... which is maybe not a bad thing  lol

No no. Don't say that. I'm sorry to see that you got so much pressure these past days. Hopefully you'll stay with us.

P.S. I never intended to insinuate that you're a pirate.. if that's what you thought. I merely, out loud generally, wondered what uses I can think of with that feature.. and only one "proper" came to my mind, and one not so "proper".

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #618 –
Quote from: Chinch on
it had two matches, but was -17 and -685 offset from my rip. now, after ripping 39 other CD's with perfect results, and i do this rip, which has matching test+copy CRC's, i can say this rip is CORRECT by simple logic.

I'm not quite sure what you were trying to say but in any case, you do know that matching T&C CRC's is not a proof of accurate rip? It doesn't matter how many (or few) CD's you've ripped ok before that. All that the matching CRC's do tell you is that the track data was read exactly the same in both test and in copy. Correct data or corrupted data.

Quote from: Chinch on
does it really matter if your rip comes back as "no matches" or shows matches with different offsets if you know you ripped yours correctly, with the correct offset, etc... or like in my situation where i have 39 match record so far... i can say quite safely that my settings are configured right. that 1 cd that came back with no matches...

But you can't tell that the CD was accurately ripped without AR. So no matches makes you fall back to the CRC's which doesn't guarantee accuracy (+ to track quality %'s). Different offset matches (all tracks within at least one offset.. and with 1 matches if it's not your own submission) are ok. The "fact" that your settings are correctly configured doesn't guarantee you accurate rips.

Quote from: Chinch on
one CD i find difficult to rip ... about halfway through the disc, it gets SUPER slow (would take like an hour or more to rip the cd fully), and i get all kinds of sync errors and re-reads over and over. the CD surface is pristine... not a single scratch, fingerprint, NOTHING. has anyone else experienced this with this particular CD if you have ripped it?

Yes I've, not with that CD but another. Bogged my mind. No visible marks, nothing. And no protections. Still had lots of problems reading it. Usually the "good" protections kick in with every track and makes EAC re-read like mad in many places within one track.. so it should not be protection with your CD. If you browse to the CD drive in Win and it has only .cda ending files, the CD doesn't have any protections.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #619 –
i get the error: "Synchronization Lost" on all builds

How do i fix this? i got .NET & C++ installed....

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #620 –
What does all the offset items have to do with the app the thread is for?

Take this to a seperate thread please.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #621 –
Would it be possible to implement a "Use gaps appended + HTOA (only when HTOA isn't empty)" switch?

Most of the time a simple PREGAP is sufficient.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #622 –
Can somebody please explain to me what happened to the other 106 matches?

Code: [Select]
D:\Music\FLAC\Albums\The White Stripes\2 De Stijl\2 De Stijl.cue: rip accurate (17/123).
[Verification date: 22.8.2009 19:37:06]
[Disc ID: 0011dcf6-00b57a59-b008d20d]
Offset applied: 667
Track	[ CRC    ] Status
 01	[6c8cd435] (18/124) Accurately ripped
 02	[35460eef] (18/126) Accurately ripped
 03	[c2da991b] (18/125) Accurately ripped
 04	[c37d7193] (18/124) Accurately ripped
 05	[654e275a] (18/125) Accurately ripped
 06	[6a655caa] (17/123) Accurately ripped
 07	[60b24313] (17/124) Accurately ripped
 08	[b79ef599] (17/123) Accurately ripped
 09	[263edf3a] (17/124) Accurately ripped
 10	[caa96eb7] (17/124) Accurately ripped
 11	[23bc4f57] (17/124) Accurately ripped
 12	[df2e22f8] (17/124) Accurately ripped
 13	[c0aaf0a9] (17/123) Accurately ripped

Track	[ CRC32  ]	[W/O NULL]	[  LOG   ]
 --	[310B18D0]	[9D75D106]	
 01	[408CDD38]	[0ACC2641]	 W/O NULL 
 02	[D763687A]	[94AE1449]	[C13C4398]
 03	[227045C4]	[9B721BB3]	[72B66554]
 04	[886A95E8]	[AC4B1540]	 W/O NULL 
 05	[9D50A2B0]	[1DA3CED4]	 W/O NULL 
 06	[80BA0F68]	[F8794B93]	 W/O NULL 
 07	[A4EC5F1B]	[210CF406]	 W/O NULL 
 08	[09063A6D]	[875F5C71]	 W/O NULL 
 09	[2D62BD5C]	[D03045F8]	 W/O NULL 
 10	[D2B51174]	[C872FF19]	[15678878]
 11	[CD0B1B5D]	[7EE51525]	[56E565D2]
 12	[21D79E04]	[A02872C6]	 W/O NULL 
 13	[90575028]	[735F8920]	 W/O NULL

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #623 –
As far as I understood, the disk ID is the same but the data is entirely different, it can be a kind of remaster (or just a reissue with some kind of audio effect, supposed to increase quality, applied) or made from another master without any bonus track, any bonus Data track or any pregap difference which would affect the disk ID. (nor any song lenght difference & so on ...) It could also be that one of the two pressings is only a reissue burned with a crap software that altered the data in some way (either corruption or weird stuff like audio watermark), I dunno, there seems to be plenty of possibilities. As the other pressings are not listed this is not just an offset issue. It seems that there is truly several pressings for this CD. I may be wrong but that's how I understand it.

Anyway your CD is accurate.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #624 –
Hii at all.

The version 2.0.4.a of the program allways working well for me.

Today after the XPSP3 live update the program now return this error and return in the initial state (waiting for press the go button):


What's append?