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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #575 –
fair is fair, and i'm not here to argue either. i don't think starting your post off with a personal insult was that tasteful, but i will try to explain the detail of why i disagree, and maybe you or the others can correct me, if i am indeed wrong.. and i don't claim to know it all, so that is possible.

Quote
are sure 100% that the rip you made by yourself has made its way thru the accuraterip database ? the anwser is NO.

no, i cannot be sure once it leaves my computer what happens with it. i do know that i manually submit my accuraterip results on a regular basis, and the submissions report to be successful.

Quote
There is plenty of reason why your own rip which could be the only result in the database has not made it's way thru the database (due to bad configuration, firewall, loss of internet connection ...). So it is not a problem of the 1 result in the database being your own rip or you being an evil pirate that checks illegal rips ...  It is the problem that you can NEVER be 100% sure that the 1 result in the database his yours or not, even if you know you ripped this CD.

this part doesn't make sense to me, i'm afraid. looking past the second or third insult, what you seem to be saying is that there is no reason to know whether an accuraterip submission/match of 1 is my own entry, or "evil pirate's" entry. aside from who it is ripping a CD, an accuraterip result is an accuraterip result. If I take my CD, put it in the drive, rip it.. and get a match of 1 (say it's dirty pirate's!)... regardless of who or what they are, their CD ripped with the same result as mine. I don't understand what that has to do with anything. how do i know it's not my own rip? well... usually i only rip my CD's once, unless there is a need to re-rip one... so I don't think EAC or dbPowerAmp is going to submit my results in real-time and check them against itself.

besides, i thought that the accuraterip DB had a mechanism that prevented multiple submissions from the same machine? if not, why is there a field in the accuraterip submission page called "computer identification"?

reference:



i could be wrong... someone who knows for sure like spoon might could say.

Quote
For the second part of your answer, well you should learn about offsets because offsets has nothing to do with accuracy, it is only usefull to actually find the CRC in the database ... my accurate rips with fixed offsets according to most popular in database is in NO WAY less accurate than your "so-called perfect rip" made with your the official pressing you bought yourself.


so if i understand you, you are saying that if i rip a CD... and it is indeed a correct rip (for this example)... and it does not match any in the DB. most popular one we'll say is -612. you take your rip, and correct the offset, that is, shift the offset of your ripped track(s) by -612... that does not change the 'accuracy' of your rip (given if is simply a different pressing that is not in the database yet)? also given those samples are not null samples.

for instance, I have a gapless track... it goes from track 2 to 3 with no gap, a seamless transition. you shift your samples by -612... you don't lose any audio data at all?

in other words, changing the offset of a correct rip to match the offset of an alternate pressing, simply to match it will never cause a loss of audio? if this is true, then i completely misunderstand the whole thing. the only way i could see this is if a certain range at the beginning and end of a track are not considered into a calculation of CRC or the data that was removed/padded were null samples. can anyone verify or deny this? this would allow for minor variances in submissions to still match. (and by minor i mean fractions of a second).

i'm just letting you know how i see things and my understanding/viewpoint of how it works. if i am wrong, then i am wrong... i'm here to learn and discuss, not to fight.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #576 –
Well your new post make much more sense to me, indeed if you go to the shop buy a CD, go home & rip it with eac or dbpoweramp, submit & get an accuracy 1 result then yes your rip is perfect. But only because you know your result & the one in the database are differents.

But IMHO you're off-topic, I am not discussing accuracy 1 in the context of EAC & DBpoweramp, but in the context of Cuetools & Cuetools is not yet a ripper.

I can have bought a CD legally, then ripped it legally without saving a log & don't recall if I submitted or not. It happened to me because in the first day of Accuraterip the database was not populated & I was not sure if I would ever use it, even if I tested it. I honestly don't recall what I ripped in these days. For these rips cuetools results with accuracy 1 are a problem for me as my ID has changed. Furthermore, experience have proved me that accuraterip database is moving ... your submission can be dropped, it happened recently for virtual drives.

Cuetools is a software, it thinks like a machine. You think like human, from your human point of view, you KNOW that your rip is perfect, because you did it & you know the submission in the database is not yours.

What does Cuetools knows about all that ? nothing. That is why I am asking for it to behave in the most basic way & report rips with accuracy 1 as Unknown. Then you're free to think that this Unknown result is safe or not.

I understand that Cuetools reports rips with accuracy 1 as accurate because it aligns itself on EAC & dbpoweramp, but what is always right in the context of EAC & dbpoweramp is not always right in the context of cuetools. Anyway even with EAC & dbpoweramp I think accuracy 1 should be treated as a special case & reported as unknown because it will help newbies understand the slight difference between accuracy 1 & accuracy 2. Reporting accuracy 1 as Unknown is good for educational purpose IMHO.

So, the question is would there be any drawback in reporting accuracy 1 as Unknown in cuetools & even in EAC & dbpoweramp. The answer as far as I know is no.

As for the second part if you would be right & if offset would break gaplessness, then the CRC would not be the same anymore because gapless means data, not silence. I understand your point better on the first part, but I think your wrong on the second part. If you were right I would have f#cked all my rips, don't give me nightmares

Edit: I think it has to do with offsets being way to small to affect any samples were songs are cutted, but I don't recall exactly. Sorry if you ever felt insulted, your questions are not stupid, I asked these questions to myself a few years ago ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #577 –
Another weird request, sorry

Would it be possible to have an option to hide the complete path in the bach log & only display the final folder name+final .cue filename, because I use my 22' LCD screen in portrait mode instead of landscape & actually 1050px is not large enough to display the complete path, I am always forced to browse my mouse to the right & it is annoying ... it will help people will lower resolution too I think.

Much sorry for annoying you with my 120% fonts in the past & now with my portrait display mode

Here is a small screenshot:

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #578 –
Quote from: sauvage78 on
Well your new post make much more sense to me, indeed if you go to the shop buy a CD, go home & rip it with eac or dbpoweramp, submit & get an accuracy 1 result then yes your rip is perfect. But only because you know your result & the one in the database are differents.

But IMHO you're off-topic, I am not discussing accuracy 1 in the context of EAC & DBpoweramp, but in the context of Cuetools & Cuetools is not yet a ripper.

I can have bought a CD legally, then ripped it legally without saving a log & don't recall if I submitted or not. It happened to me because in the first day of Accuraterip the database was not populated & I was not sure if I would ever use it, even if I tested it. I honestly don't recall what I ripped in these days. For these rips cuetools results with accuracy 1 are a problem for me as my ID has changed. Furthermore, experience have proved me that accuraterip database is moving ... your submission can be dropped, it happened recently for virtual drives.

Cuetools is a software, it thinks like a machine. You think like human, from your human point of view, you KNOW that your rip is perfect, because you did it & you know the submission in the database is not yours.

What does Cuetools knows about all that ? nothing. That is why I am asking for it to behave in the most basic way & report rips with accuracy 1 as Unknown. Then you're free to think that this Unknown result is safe or not.

I understand that Cuetools reports rips with accuracy 1 as accurate because it aligns itself on EAC & dbpoweramp, but what is always right in the context of EAC & dbpoweramp is not always right in the context of cuetools. Anyway even with EAC & dbpoweramp I think accuracy 1 should be treated as a special case & reported as unknown because it will help newbies understand the slight difference between accuracy 1 & accuracy 2. Reporting accuracy 1 as Unknown is good for educational purpose IMHO.

So, the question is would there be any drawback in reporting accuracy 1 as Unknown in cuetools & even in EAC & dbpoweramp. The answer as far as I know is no.

As for the second part if you would be right & if offset would break gaplessness, then the CRC would not be the same anymore because gapless means data, not silence. I understand your point better on the first part, but I think your wrong on the second part. If you were right I would have f#cked all my rips, don't give me nightmares 

Edit: I think it has to do with offsets being way to small to affect any samples were songs are cutted, but I don't recall exactly. Sorry if you ever felt insulted, your questions are not stupid, I asked these questions to myself a few years ago ...


well.. i suppose here is where we can meet an agreement.. as you made a good point in that CUETools is (as of now) a rip checker, and not a CD ripper, therefore you are checking the database after the fact, so i do understand your point here.

and yes, i do agree that for the most part, it seems that offset correcting is relatively harmless, as you said... since i most cases the part being removed or padded is indeed silence (or more specifically, null samples), not to mention fractions of a second as i was saying earlier... so it's not likely to matter in the 'real world' anyways i suppose. you're always going to have disagreements on this board, because there are at minimum two classes of listeners... those who are happy with their audio rips being "good enough" and those obsessed with "perfection" in ripping. otherwise this board would not be so lively with so many questions and debates over the years. it keeps the brain exercised, for sure.

so i'm thinking this.... if you apply padding to the beginning of a rip, it is going to be null samples... no audio.. which will then match the CRC. no problem. the tracks will ultimately be identical if the other one has silence as well. same with the other way... if you remove samples... as long as they're null, you're not leaving out any data.

but this brings up a new question that i never thought of before... when it reports alternative offset matches... are those offsets based on that cd as a whole, or individual track? the importance of that is the question "is it only the very beginning of the cd that is off by +000 samples or -000 samples, or every track?" my thought would be it is based on a full CD, since therefore in theory, you can pad or remove samples from only the first track... affecting only that one, or do you apply that offset to every track? if it were track based, then i could see it being a problem, since a lot of cd's these days don't have a two second gap between songs, they're gapless a lot of times... that's the scenario that would present a situation where the opportunity for loss of real audio samples is very viable.

i need to go back and hit the books on offsets, cause you have me questioning myself now... but questions are good, they lead to knowledge, as long as the information you are getting is correct. this is why i try to rely on people who have done things like coding of ripping programs, examination/comparison/experimentation with waveforms under different circumstances... as it is always possible to get misinformation or misunderstand things.. that goes for both of us. so i guess we can just hopefully agree that neither of us are true experts on the matter, and we can leave it at that, as we both have brought up valid and important points on the matter; and i accept your apology on the matter, as i apologize if i have offended you in any way either.

could anyone who really really knows their stuff (like a developer, etc) clear up a couple of those questions we have brought up and explain which statements we have made are correct or incorrect?



By the way... regarding your most recent post about the log area , sauvage, I think I can finally agree with you without debate on this one... I agree with you about the log. Personally, I preferred it on the left side instead of the bottom... takes up less of a footprint that way.. the new interface is cool, don't get me wrong... but could you maybe implement an option to show the log file on either the left OR bottom? and I agree with sauvage, maybe only show the .cue file name instead of the full path, as this is rather unimportant and adds a whole lot of horizontal scrolling that's not really necessary, especially for people with a lot of nested folders.. that string can get pretty long  the problem with showing only the last FOLDER is for the people who have it organized as \Artist\Album instead of just \Arist-Album or whatever.. it could possibly be more of a headache to write the code to determine which of the folders should be included or discarded than it would be just to show the cue file. in your example though, the name is generic, you would have to rename the original rip file to include the artist/album/year. This is personally how I do it, i output the WAV as Artist-Album-Year.wav    -- but it's all personal preference.

gregory, what about maybe some sort of tabbed thing for the diff modes, so you can just select the tab for which mode you want really quick to switch back and forth.. that might be quickest and most intuitive? just all suggestions and seeds for design thoughts, i think you're doing a great job on the program. already looking forward to the next update.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #579 –
well an option to chose the deepness of the path // displayed would make everybody agree

artist/year/album/CDImage.cue would gave

0=full path
1=CDImage.cue
2=album/CDImage.cue
3=year/album/CDImage.cue & so on ...

Edit:
quote: Myself post N°577 "affect any samples were songs are cutted" ==> "samples" should be read as "frame", cue sheets are cut by frame not sample, (the offset is given in samples, 1second=75frames, 1frame=588 samples)... I cannot edit my own post. It seems there is a time limit for edition now ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #580 –
I thing that the program should be as simple and straightforward as can be and still preform the necessary functions. If all the options are included in the basic program to satisfy everyone's quirks, the program will become too complicated for the average user.

As for the layout of the output log, everyone will never agree on one layout. If the layout has the necessary information, than leave it alone! What one person find useful, another may not, leading to never ending changes. If you know that a confidance level of 1 could be yours in some circumstances, is it really necessary that you be reminded every time that you run the program?
Glass half full!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #581 –
Quote from: bilbo on
I thing that the program should be as simple and straightforward as can be and still preform the necessary functions. If all the options are included in the basic program to satisfy everyone's quirks, the program will become too complicated for the average user.

As for the layout of the output log, everyone will never agree on one layout. If the layout has the necessary information, than leave it alone! What one person find useful, another may not, leading to never ending changes. If you know that a confidance level of 1 could be yours in some circumstances, is it really necessary that you be reminded every time that you run the program?


i agree with you here.. certain programs.. for instance.. ImgBurn.. when you first look at their options dialogue.. it's a little overwhelming. i admit a lot of that stuff in there i didn't even know what it meant. so i can understand that, the interface/options can become intimidating if it becomes too robust. on the other hand, the more configurable/customizable, etc a program is, that is great. i think EAC and some other programs have taken a good approach by having a 'simple' or 'beginner' mode, then an option to enable advanced user options.. that way the interface can be kept clean and simple, yet offer the advanced functionality and customization that a move advanced/hobbyist user would need to satisfy what they are trying to do.

it all depends on the programmer and how much time and effort they are willing to put into the program... i understand adding features and options takes time to code up, and you are indeed correct... not everyone is going to be satisfied with everything all the time.

given that...... as far as logs go, etc.. in the end, they're just plain text files, and if it comes down to it, you can always edit them, remove the path, remove the offset, make whatever modifications you want to suit your needs. it's a bit more work, but at least it's *possible* to get it in "x" format.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #582 –
From the above highly entertaining chat  , I would like to repeat the question of Chinch, because it's a question which lingered in my mind also:

Quote
for instance, I have a gapless track... it goes from track 2 to 3 with no gap, a seamless transition. you shift your samples by -612... you don't lose any audio data at all?


In other words: If an offset is applied do I lose only the samples from the first track and are all other samples moved from the subsequent track.
Or do I lose samples from all tracks?

I don't apply offset very often, but it would be nice to know what happens if I applied it to p.e. a "Live" recording.

After using 2.0.4 for a while now, I must say I like it a lot with the drag'n dropzone (or filebrowser) on the left and a resultwindow at the bottom.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #583 –
I would have to dig in old threads to find the exact answer, but offset is applied to all data. You can usually only lose real non silence samples on the last track if the drive offset is insane, that's why accuraterip ignore the last ignores last 2940 samples. If I am correct, even first track is usually safe from huge negative offset because there is almost always silence in the beginning. As for gaps, I don't recall why, I think I tested myself on a gapless Alice In Chains CD if I recall well ... gaps were not affected. This is not a scientific answer but that's what I recall from previous discussions. Anyway no sample can be lost by shifting data, even if gaps were affected, data would be shifted & not destroyed (except on last track indeed).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #584 –
Hi, I'm using the stable version of CUETools (1.9.5) and I would like to know: does this program correct the offsets by default if it find the corrected value via AccurateRip?
In other words, I've got this log, are the files generated corrected?
Code: [Select]
[Verification date: 14/08/2009 13.04.59]
[Disc ID: 001491a5-00d42732-9b0b0a0d]
Track    [ CRC    ] Status
 01    [227cc5b1] (00/08) No matches
 02    [7aa2afe3] (00/07) No matches
 03    [d9678ca5] (00/07) No matches
 04    [7a66fd12] (00/07) No matches
 05    [46d14a8a] (00/06) No matches
 06    [4bd71e44] (00/07) No matches
 07    [6a3638d9] (00/07) No matches
 08    [40a4d6cc] (00/07) No matches
 09    [287e3303] (00/07) No matches
 10    [7e027f0e] (00/07) No matches
 11    [03734de5] (00/07) No matches
 12    [4079e0f2] (00/07) No matches
 13    [5863eb0b] (00/07) No matches
Offsetted by 48:
 01    [58181c12] (08/08) Accurately ripped as in pressing(s) #1
 02    [f72940f5] (07/07) Accurately ripped as in pressing(s) #1
 03    [dac12a18] (07/07) Accurately ripped as in pressing(s) #1
 04    [763bf9ba] (07/07) Accurately ripped as in pressing(s) #1
 05    [90f62ee8] (06/06) Accurately ripped as in pressing(s) #1
 06    [da6441db] (07/07) Accurately ripped as in pressing(s) #1
 07    [bd8c400d] (07/07) Accurately ripped as in pressing(s) #1
 08    [d3ef6460] (07/07) Accurately ripped as in pressing(s) #1
 09    [a6dd0315] (07/07) Accurately ripped as in pressing(s) #1
 10    [02b7f27b] (07/07) Accurately ripped as in pressing(s) #1
 11    [ab7d547f] (07/07) Accurately ripped as in pressing(s) #1
 12    [5d1f9351] (07/07) Accurately ripped as in pressing(s) #1
 13    [ad0de8c4] (07/07) Accurately ripped as in pressing(s) #1

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #585 –
Your rip is accurate but either:
1- you have a pressing different from the one in the database & your CD pressing is +48 samples OR
2- you didn't set any offset correction when ripping & your drive's offset is -48 samples OR
3- you set a wrong offset correction & now it's something in between & you can correct your mistake by adding +48 samples.

There is no absolute correct offset, correct offset is related to a particular physical drive & a particular physical CD. Cuetools can only tell you if an offset for a CD is popular or not compared to yours. It doesn't affect quality.

PS: You should upgrade to lastest version IMHO.

Edit: 1- mixed + & -48 samples

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #586 –
Hmm, I don't understand what's the hubbub with the correct offset thing; can somebody tell me shortly why I would want to correct offsets if I find an album which has no AR matches, but other offsets have? Up until now I was under the impression that it is utterly pointless (and possibly harming) to go through with this procedure.

P.S. The "experimental" profiles system is buggy, hopefully I've time to test it properly and make notes this weekend.

P.P.S. Thanks a lot Gregory for the log amends!

@buddhabar: use CODEBOX tags for long listings.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #587 –
Thanks for the explanation, I'll try the latest version (the word "stable" had attracted me).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #588 –
Akkurat:
You can leave offset uncorrected, your rip will still be accurate. Offset have always been for paranoid people.
A rip with "No matches" with offset 0 can be perfectly accurate with offset X or Y.

But if you correct them according to the most popular in database:
1- your log will be shorter
2- popular offset are likely to be an european or USA pressing (not 100% safe)
3- you can find doublon with a dupefinder by comparing . accurip file which is faster than processing lossless files

Other than that there is no benefit & none of the above benefit is tied to quality.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #589 –
Quote from: sauvage78 on
PS: You should upgrade to lastest version IMHO.

I don't agree, there's some bugs in the profiles system, some settings are not saved/reverted back/reverted from other profile(?), profiles management bugs, etc. problems, not yet fully tested but there are clearly bugs. More later when I have more time.. though, I'm sorry but, I wonder was it tested at all prior releasing.. I found major bugs under ~15 minutes (I don't know if it's just me.. I've learned that I've a knack for testing), I hate to test and write about "easy" bugs, I wish that those would be squashed prior releasing alpha/beta/whatever. SORRY.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #590 –
Yes there are cosmetic bugs, none is major & none affected quality for me so far. IMHO the added features overweight the minor bugs. It's a matter of taste. I already warned about easy-to-find interface bugs (particulary in the profile system & advanced setting not saving correctly). Read my previous posts.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #591 –
I've tried version 2.0.4 and 2.0.3 and both give me Database access error: BadRequest when I try to connect to AccurateRip database, with 1.9.5 is all fine...

EDIT: Kaspersky 2009... mpf...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #592 –
Quote from: sauvage78 on
But if you correct them according to the most popular in database:
1- your log will be shorter

You mean the EAC log? Or what? Shorter is better because it's easier to read? Or save few KB's?

Quote from: sauvage78 on
2- popular offset are likely to be the european or USA pressing (not 100% safe)

I'm sorry but what are you trying to say here? Not safe?! Can you elaborate?

Quote from: sauvage78 on
3- you can find doublon, with dupe finder by comparing . accurip file which is faster than processing lossless files

I don't understand this either. Sorry. Finding a double? Is your memory so short that you can't remember which albums you have already ripped and archived? Or not being able to check your music collection if you already have the album there?

Quote from: sauvage78 on
You can leave offset uncorrected, your rip will still be accurate. Offset have always been for paranoid people.
A rip with "No matches" with offset 0 can be perfectly accurate with offset X or Y.

So it is utterly pointless and possibly harming like I thought.

Still, if it's only for the paranoids/fools (sorry ), how come it was coded to CUETools? Does it serve a real purpose?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #593 –
1- no I mean the cuetools log, it will be shorter as the No matches with current offset will disappear.
2- it's a question of probability, richer country buy more CD (specially european & USA teenagers) an offset with higher popularity is likely to be a pressing from a rich country with many CD buyer (& rich enough to have a PC too) for example a Pink Floyd CD with popularity 200 is VERY unlikely an south african CD pressing ... it's only logic here. But even logic it is not 100% sure as it depends on who ripped the CD in which country ... the only thing you can say is that the higher is the offset popularity the higher it has chance to be an european or USA pressing rather than a japan or russian pressing.
3- it's usefull if you have remastered or re-release with bonus version. if you & your friend have both the same CD & you don't know for sure if it's the same master. It can be usefull when the original release wasn't a CD. For example Black Sabbath CD, there is several different version or their CDs because the original realease was a tape. I have friends with Black Sabbath CD that doesn't match mine & it's not even a remaster. Indeed you can compare audio CRC, but either you have to compare manually or you have to process big files. If you search doublon by comparing .accurip with "fixed" offset according to the most popular, it's fast & automatic.

Another use is for people like me who don't bother use offset correction when ripping but still want to automatically "fix" them without even caring about them. For exemple me: Cuetools & accuraterip are so great that they have changed the way I rip & store my CD ... I used to correct offset & rip in secure mode ... now I rip in burst mode+CRC check & verify+fix offset with cuetools ... so yes it is VERY usefull for me. It is just as safe, but it is much faster. I only use secure mode when really needed now (scratched or not in database) & I will never thks Spoon & Gregory enougth for the time saved.

As always if you don't like it, don't use it. I find it very usefull. If you think it's harming then well ... life is harmfull you know  , you shouldn't turn your PC on as HDD can die & corrup your rips.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #594 –
Quote from: sauvage78 on
1- no I mean the cuetools log, it will be shorter as the No matches with current offset will disappear.

Ok. Fair enough, whatever pleases you. But think of how many times do you read your logs? Is it THAT important? I noticed that earlier Gregory suggested you to: "Uncheck 'Verbose' option for log files, and you will have shorter logs". Oh well, no need to answer anymore to this, each to their own.

Quote from: sauvage78 on
... the only thing you can say is that the higher is the offset popularity the higher it has chance to be an european or USA pressing rather than a japan or russian pressing.

AND this has a meaning? I think this underlines the whole "fix offsets" issue here. Let's say that you've bought a Polish pressing of an album, you take measures to rip it "safe", i.e. accurately, i.e. you want to make an identical digital copy of your CD. It is reported to be accurate with another offset, i.e. pressing, using CUETools, BUT then you make a decision to fix the offset, i.e. making it NOT an identical digital copy of your CD, just because you want to have a "warm & fuzzy" feeling of having the "best" rip possible. This logic escapes me. But it's a moot point discussing this further.. each to their own again.

Quote from: sauvage78 on
3- it's usefull if you have remastered or re-release with bonus version.

But aren't those completely different albums, i.e. they do have different AR disc ID's? And thus can't be compared.

As for the rest of the reasons you wrote, most of it just doesn't make sense to me. Let's leave it a that, ok?

Quote from: sauvage78 on
Another use is for people like me who don't bother use offset correction when ripping but still want to automatically "fix" them without even caring about them. For exemple me: Cuetools & accuraterip are so great that they have changed the way I rip & store my CD ... I used to correct offset & rip in secure mode ... now I rip in burst mode+CRC check & verify+fix offset with cuetools ... so yes it is VERY usefull for me. It is just as safe, but it is much faster. I only use secure mode when really needed now (scratched or not in database)

Why don't you use offset correction when ripping? Do you mean using the correct offset for your drive in EAC? I don't understand the point about secure Vs. burst mode at all, what does these have to do with the offset correction?

Quote from: sauvage78 on
If you think it's harming then well

It's not what I imagine (you meant this?), it's possible.. and what I did discover, searching this topic about this, that you have been told the same thing but I see that it has gone to deaf ears.


Some quotes:

Quote from: Gregory S. Chudov on
I already stated my opinion several times, that there's no good reason to correct offsets - some data can be lost, and nothing can be gained (unless you intend to burn the result to CD-R and want it to be identical to some pressing of the original CD)


This one answered my earlier question of why the fix offset function was coded to CUETools.
Quote from: Gregory S. Chudov on
I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation, which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.
We only needed it in the past to be able to use AccurateRip, but now we can do it without offset correction.
I will continue to support offset correction in CUETools, because there are probably a lot of people with different views,
but i'm not making it a priority.


Quote from: Gregory S. Chudov on
Personaly i find 'fix offset if' more and more useless.
Rip can be verified without changing offset, so there's usually no point in it.
You only loose some samples for no particular gain.
Especially in automatic mode, when it's not really predictable.
I.e. in your case the rip is perfectly alright as it is,
it makes no sense to apply an offset to make it similar to a more popular pressing.

I wanted to quote another one and make this post MEGA long , but the additional quote tags were too much for this forum software to show this post properly.. here's the link to that post.

In the end I can think of only one proper reason for using this fix offset feature: if somebody notices that some of the rips were done with no proper drive offset set in EAC and they know the correct offset of that drive. Any other reasons? Otherwise I see that this mostly pleases only music pirates..?

Edit reason: grammar.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #595 –
Flac encoder (don't know 'bout others 'cause don't use 'em) seems not to remember its settings and resets to default (i.e. compression=5) after restarting the program.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #596 –
acmodeu:
I had the same problem this V2.03, for me this was fixed in V2.04, plz report the version you use when you report a bug.

Akkurat:
Thks for reading back  I know the opinion of Gregory & Greynol on the topic & I agree with them on the fact that this is "useless" if you only consider that "usefull" means making your rip better. It doesn't.

So far, IMHO the supposed "risk" is just FUD as no-one has proved in a scientific way that I could damage my rip by correcting offset. 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. In all honesty I recall I tested something but I don't recall exactly as it was several months ago. Sorry. Edit: I have alot of respect for Greynol & Gregory because both have greater knowledge than me, & even if Greynol is sometime very cold in his answers because stupid questions upset him quickly, he helped me a lot in the past. Despite all this I still think that there is no reason for an irrationnal fear of offset fixing. I agree their words have a big weight here, but it have to be seconded by real life cases. Fixing offsets is just not the recommended way of doing things & I completely agree it shouldn't be a default setting.

I didn't even thought about fixing pirate rips with no offset, one more reason for some evil people to find it usefull ... but in fact as I already explained above, I rip without correcting offset & then check with cuetools because I want a cuetools log. I only re-rip to secure when EAC tells me that the rip is not in database ... so as you see I am not the kind of guy who cares for offsets (Edit:but I do care a lot for gaplessness) ... nowadays I only care for one thing, rip the fastest way possible & get an accuraterip result of 2. In a way I rip like your evil pirates, if it has a correct offset, whatever the offset is, then nice, if it doesn't I don't care. Morality has nothing to do with offsets, I want cuetools to behave like a machine & do want I order. I don't care if pirates can abuse the setting as long as it is legal to fix offset & I find it usefull.

The discussion about this setting is interesting when it deals about if it can or not damage gaplessness as I am interested by results from other people on the matter. When it drifts on the usefullness of such an option, it is IMHO a completely useless discussion, because offsets are USELESS from the start. We use offset because drives are in a way "defective by design" & as CD is a dead format, offsets is a dead flaw. 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.

Quote
But aren't those completely different albums, i.e. they do have different AR disc ID's? And thus can't be compared.

Yes, I only use it to be sure that both are different. As I said there is other ways to achive this, this one is just the fastest way I found.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #597 –
sauvage78, yes, everything seems to work fine now. Thanks for the hint.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #598 –
Greetings!

First time post and a long time user of v1.9.1 and v1.9.5 here. Lately I've had some time to check out the new version. Very nice and a big thank you to GSC for continuing development. The extra features are most welcome!

From a long time user's standpoint looking at a new version, I am mostly interested in ease of use based on my familiarity with the old version. So far it has been great!

My intial concern was why the "as in pressing(s) #x" is not available in the verbose log now.

Yes, I understand this really has no bearing on whether a track was ripped "Accurately" or not. Maybe it is truly useless information, but it is extra information about the rip that maybe some are still expecting to see.

EAC (and AccurateRip for that matter) use this nomenclature and since CUETools is inherently based on these two tools, why not use it too? It's just extra information that may or not be useful to the person using the tool, but isn't that what a verbose log is all about? I'm in agreement that it should left out of the non-verbose log so not to confuse newcomers, but that is no reason to leave it out of the verbose log. Especially when some people kinda expect to see it there.

... And yes, I have read through the older posts and understand the reasons for and against, but personally I don't see enough evidence against changing it. Especially since this is the way the app has worked from the start.

Not a deal breaker by any means, I still love the app and will continue using it. I just wanted to voice my opinion and see if anybody else agrees with me.

On a side note... GSC and Moitah, when in the future are you going to start accepting donations?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #599 –
Edit: typo
"do want I order" read "do what I order"
... the new time limit for edition is too short, I am not a native english speaker, so I correct my many mistakes several time & often add new things while correcting. It's the second time it happens to me. It will only lead me to shut my mouth ... which is maybe not a bad thing  lol