Any idea what might be causing WAC to drop the error "Unhandled exception at ASPI32.4152 -> ASSIGN-RANGE" and then crash the program?
A couple threads discussing similar error
https://web.archive.org/web/20201201180110/https://club.myce.com/t/problems-ripping-an-audio-cd/239943
https://hydrogenaud.io/index.php/topic,10387.0.html
both mention issue with TOC
It's not copy protection.
both mention issue with TOC
There are no problems with TOC, EAC extracts up to 56th track, as can be seen on the screenshot, then it crashes, I don't get a log, because it crashes before creating one.
Anything that could be done?
1 - Don't use ASPI, try native mode.
2 - Try another drive
3 - Try another software
It is native.
Drive is irrelevant.
EAC is the only true software.
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
Also, CueTools returns "Invalid stride" error.
While CueRipper does the same.
What might be done to avert it?
What other softwares could be tested?
I think I found what the problem of ripping with CueTools is:
"https://hydrogenaud.io/index.php/topic,118913.msg980695.html#msg980695"
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
It is native.
Drive is irrelevant.
EAC is the only true software.
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
Also, CueTools returns "Invalid stride" error.
While CueRipper does the same.
What might be done to avert it?
What other softwares could be tested?
I think I found what the problem of ripping with CueTools is:
"https://hydrogenaud.io/index.php/topic,118913.msg980695.html#msg980695"
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
hi
may I ask you if you have you tried dbpowramp cd ripper and EZ CD Audio Converter (in the past i had some issues with some cd and it was able to do it) ?
thanks
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
You are not making any sense to me.
Not all the drives can read that much into overburn area - especially for audio CDs. You have to find a drive that is able to read more than 90 minutes. If two programs give you error at that sort of same point, it's not software, but hardware. Try another drive.
Also, what do you mean, "150 minute soundtrack"? CueTools are designed to work with CD specification, but they're not general audio converter tool. If you want to convert audio that was not released on CDs, like some web releases of albums or web released compilations, you have to use some more generic audio converters. Foobar2000 can do conversion, also something like fre:ac, or TAudioConverter.
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
You are not making any sense to me.
Not all the drives can read that much into overburn area - especially for audio CDs. You have to find a drive that is able to read more than 90 minutes. If two programs give you error at that sort of same point, it's not software, but hardware. Try another drive.
Also, what do you mean, "150 minute soundtrack"? CueTools are designed to work with CD specification, but they're not general audio converter tool. If you want to convert audio that was not released on CDs, like some web releases of albums or web released compilations, you have to use some more generic audio converters. Foobar2000 can do conversion, also something like fre:ac, or TAudioConverter.
You're not getting the point.
It's not the drive issue, because no actual drive is involved.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
CueTools works with albums longer than 90 minutes, but I think shorter than 140, this is how I was able to rip some albums with indices exceeding 90 min mark.
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
You are not making any sense to me.
Not all the drives can read that much into overburn area - especially for audio CDs. You have to find a drive that is able to read more than 90 minutes. If two programs give you error at that sort of same point, it's not software, but hardware. Try another drive.
Also, what do you mean, "150 minute soundtrack"? CueTools are designed to work with CD specification, but they're not general audio converter tool. If you want to convert audio that was not released on CDs, like some web releases of albums or web released compilations, you have to use some more generic audio converters. Foobar2000 can do conversion, also something like fre:ac, or TAudioConverter.
You're not getting the point.
It's not the drive issue, because no actual drive is involved.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
CueTools works with albums longer than 90 minutes, but I think shorter than 140, this is how I was able to rip some albums with indices exceeding 90 min mark.
File conversion is the only solution here. Using CD rippers for this task will just cause you headaches as there is no such thing as a 150 minute audio CD.
150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log
Why do you need this?
This particular release you can download from the artist for free (https://calebhennessy.bandcamp.com/album/the-elder-scrolls-ii-daggerfall-soundtrack-revival), but that does not solve the general problem.
So this is an .img file? Created by some CD imaging software that permits this length? If so, which software?
And have you tried to open the file in say, 7z?
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
You have a CUE and some unspecified image (probably raw PCM) file, which is one of many formats you can directly rip from a CD.
Then you want to turn it into a (virtual) CD, just to rip it again?
What do you gain by doing things this way instead of using an appropriate conversion tool?
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
Wait, wait.
Firstly, that image + cue file was not made with any CD mastering tool because it's not by standard. You can make your own cue file for for example DJ mixes that are 2 hrs long, to have split points, and you can play them back in software that supports them. For fun, I've just made such file from my own compilation, it's 2hrs 35 minutes long with 24 tracks. It has wav and cue file. Cuetools won't convert it, with the same error as you are getting. And I really didn't expected it to do it.
Now, since these are files on disk, from unknown source (they could as well be made from mp3s or they may be real lossless), the only sane thing is to load them up into file converter which supports cue files and re-encode them to format of your choice, splitting songs into tracks. If cuetools won't do it, you HAVE to use other tools.
If you're sure this is 2 CD compilation someone made into one giant file with cue, you have to split it first into files, then sort them into two folders, and encode them with Cuetools as two separate CDs. If it's just a single release by someone, then processing cue file into tracks is your only option, or leave them as they are. Log files don't make any sense in this case, as you are not ripping from physical device, and since they're not CD sourced, you can't get even accuraterip readings.
If you're sure this is 2 CD compilation someone made into one giant file
Not likely that this one has ever been released on CD. The artist himself only points to YouTube and Bandcamp versions, for example.
Virtual CD images of course don't need a secure ripper, although it is admittedly neat to be able to open the same application to extract from virtual images as from actual CDs. But don't scream at EAC when your "CD image" is so far from being a CD image ...
It's not the drive issue, because no actual drive is involved.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format
You do not have to rip an image and cue file.
Foobar can read cue and image file directly, without using a virtual drive. If you open de cue file file in foobar, you can convert the tracks to wave or any other audio format that foobar supports.
It's about how to force EAC to read past 90 minute index, neither mode, nor drive, is a problem.
It worked fine with 2h rips of DVDs, but can't handle ~150 min soundtrack...
You are not making any sense to me.
Not all the drives can read that much into overburn area - especially for audio CDs. You have to find a drive that is able to read more than 90 minutes. If two programs give you error at that sort of same point, it's not software, but hardware. Try another drive.
Also, what do you mean, "150 minute soundtrack"? CueTools are designed to work with CD specification, but they're not general audio converter tool. If you want to convert audio that was not released on CDs, like some web releases of albums or web released compilations, you have to use some more generic audio converters. Foobar2000 can do conversion, also something like fre:ac, or TAudioConverter.
You're not getting the point.
It's not the drive issue, because no actual drive is involved.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
CueTools works with albums longer than 90 minutes, but I think shorter than 140, this is how I was able to rip some albums with indices exceeding 90 min mark.
File conversion is the only solution here. Using CD rippers for this task will just cause you headaches as there is no such thing as a 150 minute audio CD.
Maybe, but something must be able to rip it correctly.
150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log
Why do you need this?
Maybe it's ASD, maybe it's OCD, maybe it's irrelevant information in this enterprise.
This particular release you can download from the artist for free (https://calebhennessy.bandcamp.com/album/the-elder-scrolls-ii-daggerfall-soundtrack-revival), but that does not solve the general problem.
So this is an .img file? Created by some CD imaging software that permits this length? If so, which software?
And have you tried to open the file in say, 7z?
This is where I got it from. But indeed, the source information does not solve the problem.
This is 16 bit 44,1 kHz image+cue file that I need to rip to tracks.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
You have a CUE and some unspecified image (probably raw PCM) file, which is one of many formats you can directly rip from a CD.
Then you want to turn it into a (virtual) CD, just to rip it again?
What do you gain by doing things this way instead of using an appropriate conversion tool?
Peace of mind, sanity, you name it.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format and I need a software that can rip it from virtual image just like EAC rips physical and virtual CDs to tracks with conversion and prefferably a log, not some generic file converter.
Wait, wait.
Firstly, that image + cue file was not made with any CD mastering tool because it's not by standard. You can make your own cue file for for example DJ mixes that are 2 hrs long, to have split points, and you can play them back in software that supports them. For fun, I've just made such file from my own compilation, it's 2hrs 35 minutes long with 24 tracks. It has wav and cue file. Cuetools won't convert it, with the same error as you are getting. And I really didn't expected it to do it.
Now, since these are files on disk, from unknown source (they could as well be made from mp3s or they may be real lossless), the only sane thing is to load them up into file converter which supports cue files and re-encode them to format of your choice, splitting songs into tracks. If cuetools won't do it, you HAVE to use other tools.
If you're sure this is 2 CD compilation someone made into one giant file with cue, you have to split it first into files, then sort them into two folders, and encode them with Cuetools as two separate CDs. If it's just a single release by someone, then processing cue file into tracks is your only option, or leave them as they are. Log files don't make any sense in this case, as you are not ripping from physical device, and since they're not CD sourced, you can't get even accuraterip readings.
Indeed, CueTools and EAC give up. I was able to utilize CueTools for 2h long image+cue files, but there must be a cap somewhere, I think I've read somewhere that it's 140 minutes.
This is not 2CD compilation, it's a bandcapm download that I need to process in the same workflow as a physical CD to end format of my choice.
If you're sure this is 2 CD compilation someone made into one giant file
Not likely that this one has ever been released on CD. The artist himself only points to YouTube and Bandcamp versions, for example.
Virtual CD images of course don't need a secure ripper, although it is admittedly neat to be able to open the same application to extract from virtual images as from actual CDs. But don't scream at EAC when your "CD image" is so far from being a CD image ...
Which is why I'm looking for other CD ripping tools, but then again, if CueTools can rip longer albums, it must be doable to implement no cap in the length limit.
It's not the drive issue, because no actual drive is involved.
What I mean by 150 min soundtrack is a soundtrack that is 150 minute long in the image+cue format
You do not have to rip an image and cue file.
Foobar can read cue and image file directly, without using a virtual drive. If you open de cue file file in foobar, you can convert the tracks to wave or any other audio format that foobar supports.
Yes, I do.
dBpoweramp is a paid software, so it's out of the equation, EZ CD Ripper does not have gap hangling options like EAC and CueTools, however I tested it and it ripped the image start to back, so it is proven that it is possible to implement support for image files longer than Red Book, which again is arbitrary and initially it was to be 60 minutes, then increased to 74, then to 79,8 minutes, which didn't stop labels from releasing albums with more than 80 minutes on it, the extreme example is "Bäst of Die Ärzte [Hot Action Records - 930 003-2] (2006) counting 88:41 on disc 1, 89:07 on disc 2". So the cap limites in both EAC and CueTools has been writen manually somewhere, which means it's possible to change it either via update, or modding.
This is an image file, right? What format? .img?
I think you have confused a few things. No, you don't need a "CD" ripper.
* All the fuss about (secure) CD ripping is about getting a bitstream from a silver disc and into a file. (A CDDA doesn't have files.)
So a CD ripper needs to communicate with a particular kind of hardware device, interpret the information, act upon it - a secure drive will re-read suspicious bits, etc.
* If you have an image file, you need nothing about the physical discs of the CD drives - everything is already on file. Every bit is unique. Re-reading from the image? No more use in that than re-opening the same unaltered .txt over and over again just to see if the content has changed.
Image with cue? You only need something that can handle the cuesheet and audio-on-file.
* Indeed, some CD rippers try to check if you have an image mounted as a "virtual" CD drive, in order to disable certain functionality that is bollocks when there is no physical disc.
* This image has obviously not come directly from an audio compact disc, because there is no such audio compact disc. It has been generated by some software. Again, you need a file reader and not a CD ripper.
* ... well indeed you don't: You have been pointed at where you can get the music for free, in lossless quality.
longer than Red Book, which again is arbitrary and initially it was to be 60 minutes, then increased to 74, then to 79,8 minutes
The Red Book limit is not completely arbitrary. The format is unable to address more than 100 minutes of audio, and the lead-out area consumes some of the available addresses.
Even when using a virtual disc that has no need for a lead-out area, there is still software that relies on the Red Book addressing scheme to access the disc. There is no valid way to represent an address beyond 100 minutes, so attempting to read beyond that point results in an error. (Software that doesn't rely on the Red Book address scheme can access more than 100 minutes of the virtual CD if the virtual CD drive doesn't enforce Red Book compliance.)
In any case, there is nothing to be gained by ripping the audio again; all you need is to split it at the appropriate points. Personally, I would use a lossless compressor like FLAC to convert the raw PCM to WAV, then try shntool and see if it can handle the CUE file. Or, if I'm feeling really paranoid, I might use a hex editor to manually split the raw PCM at the appropriate byte offsets according to the indices in the CUE file.
The Red Book limit is not completely arbitrary. The format is unable to address more than 100 minutes of audio, and the lead-out area consumes some of the available addresses.
99:59:74 (max address) - 01:30:00 (lead out for 1st session must be this long) = 98:29:74 (theoretical limit). In practice it's probably much lower.
This is an image file, right? What format? .img?
I think you have confused a few things. No, you don't need a "CD" ripper.
* All the fuss about (secure) CD ripping is about getting a bitstream from a silver disc and into a file. (A CDDA doesn't have files.)
So a CD ripper needs to communicate with a particular kind of hardware device, interpret the information, act upon it - a secure drive will re-read suspicious bits, etc.
* If you have an image file, you need nothing about the physical discs of the CD drives - everything is already on file. Every bit is unique. Re-reading from the image? No more use in that than re-opening the same unaltered .txt over and over again just to see if the content has changed.
Image with cue? You only need something that can handle the cuesheet and audio-on-file.
* Indeed, some CD rippers try to check if you have an image mounted as a "virtual" CD drive, in order to disable certain functionality that is bollocks when there is no physical disc.
* This image has obviously not come directly from an audio compact disc, because there is no such audio compact disc. It has been generated by some software. Again, you need a file reader and not a CD ripper.
* ... well indeed you don't: You have been pointed at where you can get the music for free, in lossless quality.
I don't need a "CD" ripper, I need a ripper than can rip image+cue file (the format is WAV, by the way) into tracks.
I never said that the image came directly from anywhere. The lossless WAV from bandcamp was not 16/44,1, hence it was converted to 16/44,1 image+cue, I might as well try conberting it to tracks+cue and then rip, but I don't think it will do the trick.
longer than Red Book, which again is arbitrary and initially it was to be 60 minutes, then increased to 74, then to 79,8 minutes
The Red Book limit is not completely arbitrary. The format is unable to address more than 100 minutes of audio, and the lead-out area consumes some of the available addresses.
Even when using a virtual disc that has no need for a lead-out area, there is still software that relies on the Red Book addressing scheme to access the disc. There is no valid way to represent an address beyond 100 minutes, so attempting to read beyond that point results in an error. (Software that doesn't rely on the Red Book address scheme can access more than 100 minutes of the virtual CD if the virtual CD drive doesn't enforce Red Book compliance.)
In any case, there is nothing to be gained by ripping the audio again; all you need is to split it at the appropriate points. Personally, I would use a lossless compressor like FLAC to convert the raw PCM to WAV, then try shntool and see if it can handle the CUE file. Or, if I'm feeling really paranoid, I might use a hex editor to manually split the raw PCM at the appropriate byte offsets according to the indices in the CUE file.
Indeed, this is why CueTools can read longer discs, but apparently they still have a cap. Personally I would rather use something that works like EAC for physical discs, rather than a converter.
The Red Book limit is not completely arbitrary. The format is unable to address more than 100 minutes of audio, and the lead-out area consumes some of the available addresses.
99:59:74 (max address) - 01:30:00 (lead out for 1st session must be this long) = 98:29:74 (theoretical limit)
Yes, this is where the 99 min CD-Rs came in, VWestlife has a video about it.
Maybe, but something must be able to rip it correctly.
IT'S CALLED USE A "FILE CONVERTER", NOT A CD RIPPER FOR THIS TASK!
Personally I would rather use something that works like EAC for physical discs, rather than a converter.
There is no difference between EAC and an appropriate file converter for this task. You will get the same files either way, except that the converter supports more than 100 minutes of audio and EAC does not.
Maybe, but something must be able to rip it correctly.
IT'S CALLED USE A "FILE CONVERTER", NOT A CD RIPPER FOR THIS TASK!
I'M NOT INTERESTED IN A "FILE CONVERTER", I NEED A RIPPING SOFTWARE THAT CAN WORK WITH VIRTUALLY MOUNTED DRIVE WITH IMAGE+CUE LONGER THAN ~99-140 MINUTES!I'm not here to be convinced to use a file converter.
Personally I would rather use something that works like EAC for physical discs, rather than a converter.
There is no difference between EAC and an appropriate file converter for this task. You will get the same files either way, except that the converter supports more than 100 minutes of audio and EAC does not.
Perhaps, but I won't get a log, just like for ay other virtual image+cue within Red Book limits.
I'M NOT INTERESTED IN A "FILE CONVERTER", I NEED A RIPPING SOFTWARE THAT CAN WORK WITH VIRTUALLY MOUNTED DRIVE WITH IMAGE+CUE LONGER THAN ~99-140 MINUTES!
I'm not here to be convinced to use a file converter.
THAT'S THE SOLUTION TO YOUR PROBLEM! USE A FILE CONVERTER!
Perhaps, but I won't get a log, just like for ay other virtual image+cue within Red Book limits.
What good is a log when you're ripping a virtual CD? What does it tell you that you wouldn't already know by the very nature of the CD being virtual?
I'M NOT INTERESTED IN A "FILE CONVERTER", I NEED A RIPPING SOFTWARE THAT CAN WORK WITH VIRTUALLY MOUNTED DRIVE WITH IMAGE+CUE LONGER THAN ~99-140 MINUTES!
I'm not here to be convinced to use a file converter.
THAT'S THE SOLUTION TO YOUR PROBLEM! USE A FILE CONVERTER!
THAT'S THE SOLUTION TO YOUR PROBLEM! USE A FILE CONVERTER!It is not, it doesn't point to a way to rip image+cue files in the same workflow as physical CDs, neither is it a colution to fix the unhandles exception in EAC. So it's even offtopic.
Perhaps, but I won't get a log, just like for ay other virtual image+cue within Red Book limits.
What good is a log when you're ripping a virtual CD? What does it tell you that you wouldn't already know by the very nature of the CD being virtual?
I have the log, with basic information about the process, even if the drive was virtual, plus peace of mind, sanity, etc.
Also, I made Cue for the separate 16/44,1 tracks and it doesn't mount to begin with.
I have the log, with basic information about the process, even if the drive was virtual, plus peace of mind, sanity, etc.
Create your own log that just says "this wasn't a real CD". Does that work?
Also, I made Cue for the separate 16/44,1 tracks and it doesn't mount to begin with.
Does it need to?
I have the log, with basic information about the process, even if the drive was virtual, plus peace of mind, sanity, etc.
Create your own log that just says "this wasn't a real CD". Does that work?
Also, I made Cue for the separate 16/44,1 tracks and it doesn't mount to begin with.
Does it need to?
It doesn't work that way, unfortunately.
Unless EAC, or other program can start directly with Cue file, rip the image to tracks, then not really.
Unless EAC, or other program can start directly with Cue file, rip the image to tracks, then not really.
If it's already split into tracks, ripping it will give you exactly the same files. So what do you gain by turning it into a virtual CD and ripping it?
Unless EAC, or other program can start directly with Cue file, rip the image to tracks, then not really.
If it's already split into tracks, ripping it will give you exactly the same files. So what do you gain by turning it into a virtual CD and ripping it?
The tracks I mentioned were converted to be CDDA compliant.
I would gain files ripped by my preffered software, or ay other that can actually pull it off, to my preffered codec with my preffered settings (different from source), a log file, peace of mind/sanity/etc for doing it as per my workflow, potentially a modification to the original software to be able to do similar tasks in the future.
Converting audio to a virtual CD in order to rip it is the opposite of sanity.
You already have to change your workflow to handle non-CD sources anyway, so how about focusing on separating the "rip from CD" step and the "convert to preferred codec" step? That way, when you want to deal with something that isn't a CD, you can skip the "rip from CD" step.
Converting audio to a virtual CD in order to rip it is the opposite of sanity.
You already have to change your workflow to handle non-CD sources anyway, so how about focusing on separating the "rip from CD" step and the "convert to preferred codec" step? That way, when you want to deal with something that isn't a CD, you can skip the "rip from CD" step.
I am aware, but it does keep me within optimal functioning paramteres for my brain.
Sure it can be just converted, but I would preffer to keep my workflow.
The additional step is either convert to multitrack file, if the source is not CDDA, or generate a cue sheet for "tracks+cue" variant, when it is CDDA. Then it can be ripped just like every other CD, except it's mounted as virtual drive.
So, to sum up, I'm not looking for a way to convert it to my end format of preference, but how to circumvent EAC's unhandled exception, or CueTools' invalid stride, while staying in the ripping domain.
So, to sum up, I'm not looking for a way to convert it to my end format of preference, but how to circumvent EAC's unhandled exception, or CueTools' invalid stride, while staying in the ripping domain.
There is no workaround and there never will be.
I mean, you are wasting people's time here - first of all by saying you want to "rip" something that is on file and that you already have access to, that has already made people try to figure out how.
If it is image+.wav (which isn't optimal storage ...), then it isn't something to "rip".
Sure I have also been in a situation where I've been going "yes I know this can be done using a tool that is perfect for it, but I want to do it with this tool instead because that is what I know and use all the time!" - but just don't expect that to be resolved in a forum the developer doesn't even read.
Actually I even would want CUETools to convert non-CDDA (because, CUETools rules), but again, ... that doesn't seem to happen (https://github.com/gchudov/cuetools.net/issues/211). What should I do? Call up HA with misleading words that suggest I am doing something I ain't, hoping that this will make the braintrust more eager to help me in the future? (Heck, HA has a "Buddy list" functionality, but if it had an "Ignore list" you would have been on a few already.)
Oh, and: refalac (https://github.com/nu774/qaac/wiki/refalac-usage) can split cue+<suitable image file>.
I mean, you are wasting people's time here - first of all by saying you want to "rip" something that is on file and that you already have access to, that has already made people try to figure out how.
If it is image+.wav (which isn't optimal storage ...), then it isn't something to "rip".
Sure I have also been in a situation where I've been going "yes I know this can be done using a tool that is perfect for it, but I want to do it with this tool instead because that is what I know!" - but just don't expect that to be resolved in a forum the developer doesn't even read.
Actually I even would want CUETools to convert non-CDDA (because, CUETools rules), but again, ... that doesn't seem to happen (https://github.com/gchudov/cuetools.net/issues/211).
Oh, and: refalac (https://github.com/nu774/qaac/wiki/refalac-usage) can split cue+<suitable image file>.
If the people whose time is being wasted weren't engaging, if they don't know a fixture toe the error, maybe their time wouldn't be wasted.
It is image.wav+.cue, I know it's not optimal storage, this is why I'm ripping them to tracks. But it kinda is ideal for archiving, especially band-released CD-Rs.
I'm aware devs don'r lurk here. I was reading some posts about CueTools returning this error and this is where I learned that it normally woudl work with files for up to ~140 minutes, this is how I "ripped" other albums in the past that EAC would refuse to do.
I know of splitting image+cue to tracks software. Would refalac convert it to other format and leave EAC-like log afterwards though?
The error has already been described here:
https://hydrogenaud.io/index.php/topic,118913.msg980695.html#msg980695
And the list of stuff that would be nice to have in CueTools is available here:
https://hydrogenaud.io/index.php/topic,118915.0.html
If the people whose time is being wasted weren't engaging, if they don't know a fixture toe the error, maybe their time wouldn't be wasted.
There is no fix for the error. There will never be a fix for the error.
It is image.wav+.cue, I know it's not optimal storage, this is why I'm ripping them to tracks. But it kinda is ideal for archiving, especially band-released CD-Rs.
WAV doesn't have checksums, that's pretty far from ideal for archiving. (And if you're careful about how you do it, you can split them into tracks in a way that's still suitable for archiving.)
I know of splitting image+cue to tracks software. Would refalac convert it to other format and leave EAC-like log afterwards though?
No. Why do you want an EAC-like log when you're not ripping a physical CD? What would the log tell you?
If the people whose time is being wasted weren't engaging, if they don't know a fixture toe the error, maybe their time wouldn't be wasted.
There is no fix for the error. There will never be a fix for the error.
It is image.wav+.cue, I know it's not optimal storage, this is why I'm ripping them to tracks. But it kinda is ideal for archiving, especially band-released CD-Rs.
WAV doesn't have checksums, that's pretty far from ideal for archiving. (And if you're careful about how you do it, you can split them into tracks in a way that's still suitable for archiving.)
I know of splitting image+cue to tracks software. Would refalac convert it to other format and leave EAC-like log afterwards though?
No. Why do you want an EAC-like log when you're not ripping a physical CD? What would the log tell you?
If there is an error a way to fix it can be developed, maybe not by software curators, but there is always a fix possible. Since there is a cap set for CueTools, it can be changed.
I know, Red Book compliant tracks+cue is another option, but I will not delve into superiority of non-default gap handling right now.
Then refalac is ouf of the question.
The log would tell me most of the stuff a log from physical CD extraction will, it's just something I preffer to have and it all comes down to the already questioned state of my mind, which is not the subject of this inquiry. Like EAC version, extraction date, mode and settings, output format options, TOC, track details, etc, you know what's in the log.
Like EAC version, extraction date, mode and settings, output format options, TOC, track details, etc, you know what's in the log.
Most of the information in the log only makes sense when ripping a CD and is pointless for conversion.
But sure, if it makes you feel better you can write a script that calls refalac and logs the output to a file. You can do that with any other conversion tool, too.
I could adopt it as a temporary measure.
I have a ready made ffmpeg batch-conversion script. How do I add a Eac-style log generation to it I wonder (I reckon CueTools has a setting of "generate EAC-styel log", if I'm not mistaken).
I have a ready made ffmpeg batch-conversion script.
But it is not possible to set time in samples or in audio frames in ffmpeg command line tool. So splitting image+cue with ffmpeg will not be sample-accurate in most cases.
As for log, you can type it manually in Notepad.
I have a ready made ffmpeg batch-conversion script.
But it is not possible to set time in samples or in audio frames in ffmpeg command line tool. So splitting image+cue with ffmpeg will not be sample-accurate in most cases.
As for log, you can type it manually in Notepad.
I get the impression that you completely misunderstood everything I said.
In regard with ffmpeg, it was already in the conversion from source tracks stage, not image+cue ripping.
When it comes to log, I can't manually calculate CRC for example, not to mention I would know I made it manually, rather than it geing generated by software as operations, well, log, thus not being prone to human error.
So, what you want from the log is the audio checksum?
Perhaps you should choose a format that includes built-in checksums, like FLAC or WavPack. If a file becomes corrupted, you'll be able to detect it by verifying the internal checksum.
Plus, this way there's no need to convert the source audio to CD-compatible 16-bit 44.1kHz PCM.
So, what you want from the log is the audio checksum?
Perhaps you should choose a format that includes built-in checksums, like FLAC or WavPack. If a file becomes corrupted, you'll be able to detect it by verifying the internal checksum.
Plus, this way there's no need to convert the source audio to CD-compatible 16-bit 44.1kHz PCM.
I want everything that is in a log to be written by the riping/conversion program in EAC-style.
I won't be redoing my entire library in another format.
The only need is that EAC/CueTools doesn't rip images that are not 16/44,1.
CueTools source code is available online, surely someone with skills could dig up the piece of code that needs to be changed to work with longer images.
I'm a little OCD with my collecton, still refusing to acknowledge any source outside of CD just so that I can have verified rips (AccurateRip/CTDB), but the thought of creating fake rip logs makes me really uncomfortable.
I never said that the image came directly from anywhere. The lossless WAV from bandcamp was not 16/44,1, hence it was converted to 16/44,1 image+cue
I know you're not going to accept anything other than what you're asking for (which I can't imagine will ever happen), but you should have come up with a new workflow for non-CD source material, which is what I'll need to do eventually. The fact that you've lost the authentic original source material just so you can create an image that you can in turn create fake rip logs from is crazy (to me, I appreciate that to you it obviously feels very different). I can't begin to understand your issues, but can you not focus on the authenticity of your collection, rather than the existence of a bunch of text files that mean nothing?
I'm a little OCD with my collecton, still refusing to acknowledge any source outside of CD just so that I can have verified rips (AccurateRip/CTDB), but the thought of creating fake rip logs makes me really uncomfortable.
I never said that the image came directly from anywhere. The lossless WAV from bandcamp was not 16/44,1, hence it was converted to 16/44,1 image+cue
I know you're not going to accept anything other than what you're asking for (which I can't imagine will ever happen), but you should have come up with a new workflow for non-CD source material, which is what I'll need to do eventually. The fact that you've lost the authentic original source material just so you can create an image that you can in turn create fake rip logs from is crazy (to me, I appreciate that to you it obviously feels very different). I can't begin to understand your issues, but can you not focus on the authenticity of your collection, rather than the existence of a bunch of text files that mean nothing?
I just have bigger OCD than you.
I am looking for an alternative software than can handle what EAC and CueTools cannot.
I haven't lost the source material, it's just if the source material is WAV digital download, it get's converted to image+cue so that I can rip it like a normal CD. Unless it's a DVD, or Blu-Ray, for which I use DVDAudioExtractor, of which I remembered just now, so if there is an option to make a DVD folder structure of the source material I could rpi it with DVDae and let it go. In fact, I was converting someone's audio cassette to specifically DVD, so I might still have the software for that in the bowels of my computer.
I cannot.
I want everything that is in a log to be written by the riping/conversion program in EAC-style.
That is not going to
log what actually took place, and it is not capable of logging the track durations except by coincidence.
I just have bigger OCD than you.
A medical professional will be able to help you with that better than we will.
I haven't lost the source material, it's just if the source material is WAV digital download, it get's converted to image+cue so that I can rip it like a normal CD.
But it's not a normal CD, so you can't use tools that only support normal CDs.
I just have bigger OCD than you.
A medical professional will be able to help you with that better than we will.
I haven't lost the source material, it's just if the source material is WAV digital download, it get's converted to image+cue so that I can rip it like a normal CD.
But it's not a normal CD, so you can't use tools that only support normal CDs.
Most likely, but that's not the point.
Yes, hence I'm looking for alternate solutiosn that EAC that don't simplify it down to file converter, I do have a batch ffmpeg script, but I really would like to avoid using it. If noone knows what to tweak in CueTools sourecode, then I might make a DVD-A of the 24 bit source files, as they are 44,1kHz.
If noone knows what to tweak in CueTools sourecode, then I might make a DVD-A of the 24 bit source files, as they are 44,1kHz.
You don't know what are you doing and what software does, and that is the base of your endless tirade here. "When three people tells you you're drunk, you have to sit down", is an old proverb here.
Everyone told you what you should do, as your current request doesn't make any sense. Want complicated stuff? Split files to 2 CDs length worth, burn audio CDs and rip them with EAC. You'll get to use EAC, you'll get log files for 2 CD compilation, just please stop polluting the board with your nonsense, as it is clear you're not here to learn, you know best and know everything.
Yes, hence I'm looking for alternate solutiosn that EAC that don't simplify it down to file converter,
You won't find one here. The correct way to handle changing a file of one format into another format is file conversion.
I do have a batch ffmpeg script, but I really would like to avoid using it.
You don't have to use ffmpeg. There are other file converters out there.
I might make a DVD-A of the 24 bit source files, as they are 44,1kHz.
What does this accomplish that a file converter does not? Don't say a log file, because you can get those by scripting your file converter to output text to a file.
If noone knows what to tweak in CueTools sourecode, then I might make a DVD-A of the 24 bit source files, as they are 44,1kHz.
You don't know what are you doing and what software does, and that is the base of your endless tirade here. "When three people tells you you're drunk, you have to sit down", is an old proverb here.
Everyone told you what you should do, as your current request doesn't make any sense. Want complicated stuff? Split files to 2 CDs length worth, burn audio CDs and rip them with EAC. You'll get to use EAC, you'll get log files for 2 CD compilation, just please stop polluting the board with your nonsense, as it is clear you're not here to learn, you know best and know everything.
The release is not 2-disc album, so I'm not splitting it into two CDs.
If I didn't know what I was doing, I wouldn't be doing it. The fact that I do things not do thing in the orthodox way doesn't mean I don't know what the programs I use do.
Once again, my question wasn't "what am I supposed to do", but "how to circumvent the error, while still maintaining my workflow, that I never asked to be eavluated by any person".
It's very clear that I ma here to learn. To learn how to override the error, not how to do thing differently. While I do appreciate you considering me to know best and everything, unfortunately it's not yet the case. Now if you don't know the answer to my question, you opinion won't bring anything new to the table.
Yes, hence I'm looking for alternate solutiosn that EAC that don't simplify it down to file converter,
You won't find one here. The correct way to handle changing a file of one format into another format is file conversion.
I do have a batch ffmpeg script, but I really would like to avoid using it.
You don't have to use ffmpeg. There are other file converters out there.
I might make a DVD-A of the 24 bit source files, as they are 44,1kHz.
What does this accomplish that a file converter does not? Don't say a log file, because you can get those by scripting your file converter to output text to a file.
Sure, as long as that process behaves like EAC and generates me EAC-like log.
Sure, I just so happen to have a batch script I compiled some time ago.
It will fall under the category of DVD/Blu-Ray that I rpi with DVDae and comply with my workflow for such entities, if CueTools cannot be modified to accept past 140 minutes, or EAC past the Red Book restriction.
You can also download the album as a Flac zip file. All the tracks (77) are already separated. No need to rip.
Also the quality of the flac file (44,1 khz 24 bits) is better than CD quality (44,1 khz 16 bits)
Only one downside .... No EAC log.
But you can always try to convince a hardware cdr manufacturer to develop a cd drive and disc that can hold up to 2,5 hours of music.
After that is done EAC can be modified to burn and rip your image in order for you to have a EAC log.
So you can finally listen to the music in peace without the very imported (to you) EAC.log. Cause we all know the music sounds so much better with a freshly ripped EAC.log
It's very clear that I ma here to learn. To learn how to override the error, not how to do thing differently.
And we have told you, several times now, that the only way around that error is to do things differently.
Sure, as long as that process behaves like EAC and generates me EAC-like log.
What does "behaves like EAC" mean? Specifically which behaviors are you looking for?
What does "EAC-like log" mean? Specifically which information do you want to see in the log? Most of the information in an EAC log only makes sense when ripping audio from a physical CD, so you must be extremely specific about what you want to see in the log for us to help you get what you want. Manually type up an example log with placeholder data so we can see what you want your log to say when you convert your files.
It will fall under the category of DVD/Blu-Ray that I rpi with DVDae and comply with my workflow for such entities, if CueTools cannot be modified to accept past 140 minutes, or EAC past the Red Book restriction.
Why aren't you using CueTools or EAC for DVD and Blu-Ray audio?
You can also download the album as a Flac zip file. All the tracks (77) are already separated. No need to rip.
Also the quality of the flac file (44,1 khz 24 bits) is better than CD quality (44,1 khz 16 bits)
Only one downside .... No EAC log.
But you can always try to convince a hardware cdr manufacturer to develop a cd drive and disc that can hold up to 2,5 hours of music.
After that is done EAC can be modified to burn and rip your image in order for you to have a EAC log.
So you can finally listen to the music in peace without the very imported (to you) EAC.log. Cause we all know the music sounds so much better with a freshly ripped EAC.log
This is how I got the album in the first place. The thing is, 24-bit Flac is not the format I store the collection on PC for daily use, hence I have a workflow.
Remind me again, where I wanted to burn an actual physiocal disc out of this album.
Software can be modified without this.
It's very clear that I ma here to learn. To learn how to override the error, not how to do thing differently.
And we have told you, several times now, that the only way around that error is to do things differently.
I'm wasn't asking for what alternative method I should use, but how to modify the software so that it would work past the current limit.
If there is a hard cap set in both, they can be changed at the source code level.
Sure, as long as that process behaves like EAC and generates me EAC-like log.
What does "behaves like EAC" mean? Specifically which behaviors are you looking for?
What does "EAC-like log" mean? Specifically which information do you want to see in the log? Most of the information in an EAC log only makes sense when ripping audio from a physical CD, so you must be extremely specific about what you want to see in the log for us to help you get what you want. Manually type up an example log with placeholder data so we can see what you want your log to say when you convert your files.
Everything there is in a log:
Exact Audio Copy V1.3 from 2. September 2016
EAC extraction logfile from DATE, TIME
ARTIST / ALBUM
Used drive : DiscSoftVirtual Adapter: 1 ID: 2
Read mode : SETTING
Utilize accurate stream : SETTING
Defeat audio cache : SETTING
Make use of C2 pointers : SETTING
Read offset correction : SETTING
Overread into Lead-In and Lead-Out : SETTING
Fill up missing offset samples with silence : SETTING
Delete leading and trailing silent blocks : SETTING
Null samples used in CRC calculations : SETTING
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to next track
Used output format : Encoder
Selected bitrate : SETTING
Quality : SETTING
Add ID3 tag : SETTING
Command line compressor : PATH
Additional command line options : SETTING
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
Track 1
Filename
Pre-gap length 0:00:02.00
Peak level 100.0 %
Extraction speed DATA
Track quality DATA
Test CRC DATA
Copy CRC DATA
AccurateRip database DATA
Copy OK
AccurateRip database
No errors occurred
End of status report
---- CUETools DB Plugin V2.1.6
[CTDB TOCID: DATA] disk not present in database
Submit result: unrecognized or virtual drive
==== Log checksum DATA ====
It will fall under the category of DVD/Blu-Ray that I rpi with DVDae and comply with my workflow for such entities, if CueTools cannot be modified to accept past 140 minutes, or EAC past the Red Book restriction.
Why aren't you using CueTools or EAC for DVD and Blu-Ray audio?
Do they rip DVDs and BDs?
Remind me again, where I wanted to burn an actual physiocal disc out of this album.
In case you do not know. EAC was made to rip music from a cd. You want to rip with EAC to have a EAC.log
So you have to burn a cd to rip the cd with EAC to get the EAC.log
Remind me again, where I wanted to burn an actual physiocal disc out of this album.
In case you do not know. EAC was made to rip music from a cd. You want to rip with EAC to have a EAC.log
So you have to burn a cd to rip the cd with EAC to get the EAC.log
No, I don't. In case you do not know. It's enough to mount the image on a virtual drive in Daemon Tools and it works just fine under ~90-99 minutes.
No, I don't.
Try to learn and understand for what reason EAC was developed. If you do then you will see that ripping an image file in a virtual drive with EAC is total nonsense.
No, I don't.
Try to learn and understand for what reason EAC was developed. If you do then you will see that ripping an image file in a virtual drive with EAC is total nonsense.
It does what I need most of the time for both physical discs and virtually mounted disc coming either as an image+cue from previous rip from a physical CD, or artificially created from a digital download.
I wasn't asking to evaluate my methods and workflow, so your comment offtopic and unrelated to my inquiry.
I wasn't asking to evaluate my methods and workflow, so your comment offtopic and unrelated to my inquiry.
Remind me, where was i evaluation your work flow?
No, I don't.
ripping an image file in a virtual drive with EAC is total nonsense.
You pretty much summed it up here. It is neither the nature of my inquiry, nor will it impact in anyway how I process releases I acquire, not to mention it doesn't solve the problem described in post number 1.
I wasn't asking to evaluate my methods and workflow, so your comment offtopic and unrelated to my inquiry.
Remind me, where was i evaluation your work flow?
There is nothing wrong with your workflow. It is just the software that is so badly designed.
You pretty much summed it up here. It is neither the nature of my inquiry, nor will it impact in anyway how I process releases I acquire, not to mention it doesn't solve the problem described in post number 1.
The fault that you describe in the first post is caused by you. The solution is for you to change and not the world around you
You pretty much summed it up here. It is neither the nature of my inquiry, nor will it impact in anyway how I process releases I acquire, not to mention it doesn't solve the problem described in post number 1.
The fault that you describe in the first post is caused by you. The solution is for you to change and not the world around you
I don't need to change world, only to modify my copy of the software so that it carries on ripping past the currently set cap, either EAC, or CueTools.
I'm wasn't asking for what alternative method I should use, but how to modify the software so that it would work past the current limit.
If there is a hard cap set in both, they can be changed at the source code level.
The limit is at the SCSI command set level. But please, feel free to contact the T10 committee and explain why you need SCSI updated to support impossibly large CDs.
Everything there is in a log:
Okay, let's see what that would actually look like:
My EAC Impersonation Script, last modified DATE
Conversion logfile from DATE, TIME
ARTIST / ALBUM
Used drive : n/a
Read mode : n/a
Utilize accurate stream : n/a
Defeat audio cache : n/a
Make use of C2 pointers : n/a
Read offset correction : n/a
Overread into Lead-In and Lead-Out : n/a
Fill up missing offset samples with silence : n/a
Delete leading and trailing silent blocks : n/a
Null samples used in CRC calculations : n/a
Used interface : n/a
Gap handling : n/a
Used output format : Encoder
Selected bitrate : SETTING
Quality : SETTING
Add ID3 tag : SETTING
Command line compressor : PATH
Additional command line options : SETTING
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | n/a | n/a | n/a | n/a
Track 1
Filename DATA
Pre-gap length n/a
Peak level DATA
Extraction speed n/a
Track quality n/a
Test CRC n/a
Copy CRC n/a
n/a
Conversion OK
1 track(s) converted
No errors occurred
End of status report
---- CUETools DB Plugin n/a
[CTDB TOCID: n/a] not a disc
Submit result: not a disc
==== Log checksum n/a ====
Anything I've replaced with "n/a" is meaningless outside of ripping a physical CD. Does this look good? Or do you think something is missing?
Do they rip DVDs and BDs?
Do they convert FLAC files downloaded from Bandcamp?
I don't need to change world, only to modofy my copy of the software so that it carries on ripping past the currently set cap, either EAC, or CueTools.
Ah, you have found the solution to your problem. You only have to learn to program and remove the cap.
Release this improved version for me too so I can also rip these image files
But please, feel free to contact the T10 committee and explain why you need SCSI updated to support impossibly large CDs.
There no need to contact the T10 committee. SF01 has found the solution. SF01is going to remove the cap in the software.
I am looking forward to that.
I don't need to change world, only to modofy my copy of the software so that it carries on ripping past the currently set cap, either EAC, or CueTools.
Ah, you have found the solution to your problem. You only have to learn to program and remove the cap.
Release this improved version for me too so I can also rip these image files
Excellent. I'm browsing through previous versions of CueTools and apparently version 1.9.1 works perfectly fine with longer cues, so the problem happeed along the way. I will be now testing other previous versions.
I'm wasn't asking for what alternative method I should use, but how to modify the software so that it would work past the current limit.
If there is a hard cap set in both, they can be changed at the source code level.
The limit is at the SCSI command set level. But please, feel free to contact the T10 committee and explain why you need SCSI updated to support impossibly large CDs.
How does that affect virtual drives?
Everything there is in a log:
Okay, let's see what that would actually look like:
My EAC Impersonation Script, last modified DATE
Conversion logfile from DATE, TIME
ARTIST / ALBUM
Used drive : n/a
Read mode : n/a
Utilize accurate stream : n/a
Defeat audio cache : n/a
Make use of C2 pointers : n/a
Read offset correction : n/a
Overread into Lead-In and Lead-Out : n/a
Fill up missing offset samples with silence : n/a
Delete leading and trailing silent blocks : n/a
Null samples used in CRC calculations : n/a
Used interface : n/a
Gap handling : n/a
Used output format : Encoder
Selected bitrate : SETTING
Quality : SETTING
Add ID3 tag : SETTING
Command line compressor : PATH
Additional command line options : SETTING
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | n/a | n/a | n/a | n/a
Track 1
Filename DATA
Pre-gap length n/a
Peak level DATA
Extraction speed n/a
Track quality n/a
Test CRC n/a
Copy CRC n/a
n/a
Conversion OK
1 track(s) converted
No errors occurred
End of status report
---- CUETools DB Plugin n/a
[CTDB TOCID: n/a] not a disc
Submit result: not a disc
==== Log checksum n/a ====
Anything I've replaced with "n/a" is meaningless outside of ripping a physical CD. Does this look good? Or do you think something is missing?
Every n/a from from start to after TOC can use the options set in EAC.
TOC can be generated from the image+cue.
CTDB does work with virtual discs.
Checksum is generated for virtual disc rips.
Other than that this is exactly what I need.
Do they rip DVDs and BDs?
Do they convert FLAC files downloaded from Bandcamp?
If they are CDDA-compliant they do, unless I get the error described at the start. Which is why I will be testing previous versions of CueTools, because version 1.9.1 does in fact process my cuesheet.
For DVDs and BDs I use DVDae, I don't rip it to 16/44,1 from 48kHz source to then mount it as virtual image, but now that you mention it, maybe I should.
Excellent. I'm browsing through previous versions of CueTools and apparently version 1.9.1 works perfectly fine with longer cues, so the problem happeed along the way. I will be now testing other previous versions.
Let me know which version is working with these long cues. I can't wait to rip these in a virtual drive. Finally the error correction can do its job and maybe spot a C2 error.
Every n/a from from start to after TOC can use the options set in EAC.
But those options only apply to audio ripped from a physical CD. They don't apply to a bunch of FLAC files downloaded from the internet.
TOC can be generated from the image+cue.
But the FLAC files aren't valid CDDA, and even if you convert them to valid CDDA the track boundaries don't line up with a CD TOC.
CTDB does work with virtual discs.
But this isn't a virtual disc, it's a bunch of FLAC files downloaded from the internet.
Checksum is generated for virtual disc rips.
But this isn't a virtual disc, it's a bunch of FLAC files downloaded from the internet.
Every n/a from from start to after TOC can use the options set in EAC.
But those options only apply to audio ripped from a physical CD. They don't apply to a bunch of FLAC files downloaded from the internet.
TOC can be generated from the image+cue.
But the FLAC files aren't valid CDDA, and even if you convert them to valid CDDA the track boundaries don't line up with a CD TOC.
CTDB does work with virtual discs.
But this isn't a virtual disc, it's a bunch of FLAC files downloaded from the internet.
Checksum is generated for virtual disc rips.
But this isn't a virtual disc, it's a bunch of FLAC files downloaded from the internet.
Doesn't matter to me.
Who said anything about FLAC files? I never use flac files. And yet for every rip I do from virtually mounted disc the log always does TOC, so the data is available.
I get the impression you're not paying attention, let me reiterate: image+cue mounted in Daemon Tools Lite, pretty much a disc in a virtual drive.
I get the impression you're not paying attention, let me reiterate: image+cue mounted in Daemon Tools Lite, pretty much a disc in a virtual drive.
Look, when you are getting something right - why do you refuse following up on it?
The release is not 2-disc album, so I'm not splitting it into two CDs.
You do not want to make 2 CDs out of something that was never a 2CD album. Fine. But then:
You shouldn't try to make 1 CD out of something that was never a 1CD album and could never have been and can never be a 1CD album.
If you insist on making CDs - with all the issues that incur - then what is so much worse about making a "CD release that could even have existed"? Heck, contact the artist on Bandcamp and offer $$s for a CDDA edition - if they supply it, you will get a 2CD (or more), and the track lenghts will be marginally different.
Once again, my question wasn't "what am I supposed to do", but "how to circumvent the error
... no, that is what you need to understand: you circumvent the
error by learning not to do that error.
Who said anything about FLAC files? I never use flac files.
Bandcamp said something about FLAC files when you were offered download options.
Why did you select WAVE then? CDs don't contain WAVE files.
I get the impression you're not paying attention
Get the same impression when responding to your posts
Look, when you are getting something right - why do you refuse following up on it?
The release is not 2-disc album, so I'm not splitting it into two CDs.
You do not want to make 2 CDs out of something that was never a 2CD album. Fine. But then:
You shouldn't try to make 1 CD out of something that was never a 1CD album and could never have been and can never be a 1CD album.
To rip it utilizing my workflow.
If you insist on making CDs - with all the issues that incur - then what is so much worse about making a "CD release that could even have existed"? Heck, contact the artist on Bandcamp and offer $$s for a CDDA edition - if they supply it, you will get a 2CD (or more), and the track lenghts will be marginally different.
There is no distinction on bandcamp to Disc 1 and 2, I don't think Bandcamp even supports this, other than in manual description, spotify does, but it's not on spotify, hence all tracks are as one component of the release.
Once again, my question wasn't "what am I supposed to do", but "how to circumvent the error
... no, that is what you need to understand: you circumvent the error by learning not to do that error.
Taking a different route won't make the obstacle disappear from the current route. And I'm not going to be convinced to alter my workflow.
Who said anything about FLAC files? I never use flac files.
Bandcamp said something about FLAC files when you were offered download options.
Why did you select WAVE then? CDs don't contain WAVE files.
Because it's uncompressed, because this is how I store an archive copy of the Bandcamp zip, because this is the format I then use as source for cassette recording, if I'm making a recording on cassette of specific album. CDs don't contain flac either. WAV is LPCM, CDs are LPCM, so WAV will retan all samples from CD. In short, because I preffer it over flac and it's easier to work with when given a choice. When the source is already a compressed lossless, like flac, ape, wv, etc, it will still mount as virtual disc and rip, so this point is irrelevant to the inquiry. I could be using 128kbps mp3 as source and follow the same workflow and it would still mount and software would still rip, that's not the point.
Look, when you are getting something right - why do you refuse following up on it?
The release is not 2-disc album, so I'm not splitting it into two CDs.
You do not want to make 2 CDs out of something that was never a 2CD album. Fine. But then:
You shouldn't try to make 1 CD out of something that was never a 1CD album and could never have been and can never be a 1CD album.
To rip it utilizing my workflow.
You are not ripping it. Stop pretending that you ever did.
What you have done, is to prepare a table-of-contents that would have been appropriate for
mastering a CD image from files and then burning it - had it been possible to fit into the CD standard (which it isn't, just like a too large file does not fit a floppy disk ... actually for more reasons in addition).
Even if you had files that
did originate from a CD, the "image" you are viewing would not be a CD. It would be the audio and track boundaries of what it would have burned to a CD - and in this case it isn't.
If you want to pretend these files originated from a physical disc, then ... DVD.
If you insist on making CDs - with all the issues that incur - then what is so much worse about making a "CD release that could even have existed"? Heck, contact the artist on Bandcamp and offer $$s for a CDDA edition - if they supply it, you will get a 2CD (or more), and the track lenghts will be marginally different.
There is no distinction on bandcamp to Disc 1 and 2
So why are you insisting that they are all in CD1
when that is obviously false? Stop doing that. They are not. Never have been.
There is however a way to distinguish out "is surely not CD" and "is surely not a single CD".
Once again, my question wasn't "what am I supposed to do", but "how to circumvent the error
... no, that is what you need to understand: you circumvent the error by learning not to do that error.
Taking a different route won't make the obstacle disappear
The error is on you. The "obstacle" is pretty much like (well even worse than) trying to fit too much data onto a 3.5" floppy ... well the obstacle is the idea that you can. Get rid of that obstacle first.
Some of you guys have the patience of a Saint.
Look, when you are getting something right - why do you refuse following up on it?
The release is not 2-disc album, so I'm not splitting it into two CDs.
You do not want to make 2 CDs out of something that was never a 2CD album. Fine. But then:
You shouldn't try to make 1 CD out of something that was never a 1CD album and could never have been and can never be a 1CD album.
To rip it utilizing my workflow.
You are not ripping it. Stop pretending that you ever did.
Call the process however you want. EAC rips discs, same applies to virtually mounted CD images, just like DVDae will rip audio from cirtually mounted DVD/BD image files.
What you have done, is to prepare a table-of-contents that would have been appropriate for mastering a CD image from files and then burning it - had it been possible to fit into the CD standard (which it isn't, just like a too large file does not fit a floppy disk ... actually for more reasons in addition).
Even if you had files that did originate from a CD, the "image" you are viewing would not be a CD. It would be the audio and track boundaries of what it would have burned to a CD - and in this case it isn't.
If you want to pretend these files originated from a physical disc, then ... DVD.
I know how my workflow looks. Congratulations, you just reinvented the definition of a cue file, that's not the point and is completely irrelevant to my inquiry.
If the method to modify EAC, or CueTools will not be found, I will make a DVD-Audio from source files, no problem there.
If you insist on making CDs - with all the issues that incur - then what is so much worse about making a "CD release that could even have existed"? Heck, contact the artist on Bandcamp and offer $$s for a CDDA edition - if they supply it, you will get a 2CD (or more), and the track lenghts will be marginally different.
There is no distinction on bandcamp to Disc 1 and 2
So why are you insisting that they are all in CD1 when that is obviously false? Stop doing that. They are not. Never have been.
There is however a way to distinguish out "is surely not CD" and "is surely not a single CD".
They are not divided into components, hence they are 1-component release, just like 1CD, 1DVD, 1BD, 1VHS releases. You think that when I have multi format multicomponent releases, like Metallica's Super Deluxe Edition box-set I would umber them differently? like Kill Em All DVD 1, Kill Em All CD 1, etc? No, they are all Kill Em All Disc X for all formats, especially that Master of Puppets contains a cassette.
Once again, my question wasn't "what am I supposed to do", but "how to circumvent the error
... no, that is what you need to understand: you circumvent the error by learning not to do that error.
Taking a different route won't make the obstacle disappear
The error is on you. The "obstacle" is pretty much like (well even worse than) trying to fit too much data onto a 3.5" floppy ... well the obstacle is the idea that you can. Get rid of that obstacle first.
I didn't program the limitations. The analogy is flawed, as virtual disc can fit without any limitations and as mentioned previously earlier versions of CueTools processed it flawlessly, EZ CD Audio Converter and dbpoweramp too, they lack however the functionalities that are required. The idea that I can comes from past experiences, where it was doable, hence the obstacle is within the software so that it blocks operation after certain point.
I'm not interested in anyone suggesting I change the workflow, or compromise on the methods, the inquiry is about circumventing the error while maintaining the workflow entirely, whether anyone agrees with my workflo, or not, regardless of anyone's opinion about my sanity as well.
I didn't program the limitations.
To answer your first post. There is nothing wrong with EAC. The fault EAC generates is because you are not using to EAC for its intended purpose.
There is no "cap" ,as you call it , or any other limitation to remove or overcome in EAC.
Your "workflow" is the limiting factor in this case.
And I'm not going to be convinced to alter my workflow.
But you already did alter your workflow in order to rip audio from DVDs. Why can't you do that again? One workflow for CDs, one workflow for DVDs, and one workflow for random files downloaded from the internet.
I'm not interested in anyone suggesting I change the workflow, or compromise on the methods, the inquiry is about circumventing the error while maintaining the workflow entirely, whether anyone agrees with my workflo, or not, regardless of anyone's opinion about my sanity as well.
Well, either you will change your workflow by utilizing other software, or you will learn programming and change CueTools for your own needs, program entirely new software, or pay someone else to do it - in any case, choice is there, so start acting on it.
That's all there is, really. You are going against the standards, so you have to use nonstandard means to achieve your goal.
And I'm not going to be convinced to alter my workflow.
But you already did alter your workflow in order to rip audio from DVDs. Why can't you do that again? One workflow for CDs, one workflow for DVDs, and one workflow for random files downloaded from the internet.
I never altered my workflow for the DVDs and BDs, just as I didn't for VHS tapes. I did alter the workflow for albums longer than 99 minutes, here comes CueTools as a temporary replacement.
I'm not interested in anyone suggesting I change the workflow, or compromise on the methods, the inquiry is about circumventing the error while maintaining the workflow entirely, whether anyone agrees with my workflo, or not, regardless of anyone's opinion about my sanity as well.
Well, either you will change your workflow by utilizing other software, or you will learn programming and change CueTools for your own needs, program entirely new software, or pay someone else to do it - in any case, choice is there, so start acting on it.
That's all there is, really. You are going against the standards, so you have to use nonstandard means to achieve your goal.
Since noone was able to procure a solution. For now I'm testing earlier versions of CueTools, as on their website there was a like to one of the creator's website, where last version they worked with was available, the 1.9.1 and it did process my Cue file.
I never altered my workflow for the DVDs and BDs, just as I didn't for VHS tapes.
Who said anything about altering your workflows? I said you need a different workflow. You don't use your CD workflow for DVDs because DVDs are not CDs. So why do you insist on using your CD workflow for files downloaded from the internet when files downloaded from the internet are not CDs?
Well there is some software that can make them look like they were a CD. And being entitled to "Call the process however you want" (https://hydrogenaud.io/index.php/topic,122643.msg1020642.html#msg1020642) ... then it is called a CD and reading the files is called ripping a CD. And thus CD rippers that disagree, are in "error".
Right?
I never altered my workflow for the DVDs and BDs, just as I didn't for VHS tapes.
Who said anything about altering your workflows? I said you need a different workflow. You don't use your CD workflow for DVDs because DVDs are not CDs. So why do you insist on using your CD workflow for files downloaded from the internet when files downloaded from the internet are not CDs?
Because both image+cue and tracks+cue (only red-book compliant cues, which means with correctly ripped pregaps) can be done like physical CDs, so for loose tracks source there is only a cue required and they can follow the same workflow.
But your standpoint does indeed make me reavaluate the way I handle 48kHz sources. It might be more beneficial to treat them like DVDs and preserve the sample rate, than resampling to process like CD and CD-like sources.
Because both image+cue and tracks+cue (only red-book compliant cues, which means with correctly ripped pregaps) can be done like physical CDs, so for loose tracks source there is only a cue required and they can follow the same workflow.
Isn't that a new workflow? Convert loose files into image+cue?
Couldn't you have a workflow to convert loose files directly into your destination format? Then you won't have to worry about Red Book compliance anymore.
The whole reason your CD workflow doesn't work here is because your cue is not Red Book compliant: Red Book does not allow a CD to be longer than 100 minutes.
Because both image+cue and tracks+cue (only red-book compliant cues, which means with correctly ripped pregaps) can be done like physical CDs, so for loose tracks source there is only a cue required and they can follow the same workflow.
Isn't that a new workflow? Convert loose files into image+cue?
Couldn't you have a workflow to convert loose files directly into your destination format? Then you won't have to worry about Red Book compliance anymore.
The whole reason your CD workflow doesn't work here is because your cue is not Red Book compliant: Red Book does not allow a CD to be longer than 100 minutes.
An adaptation of an already existing one. Conversion to image+cue only takes place when the source files aren't alread 16/44,1, in which case a they are directly loaded up with a cue file for processing.
No.
CueTools has no problem with cues longer than 100 minutes, apparently up to a point though and only in recent versions.
No.
Why not?
CueTools has no problem with cues longer than 100 minutes, apparently up to a point though and only in recent versions.
Good for you. But the reason those longer cues fail is still because they're not Red Book compliant.
No.
Why not?
CueTools has no problem with cues longer than 100 minutes, apparently up to a point though and only in recent versions.
Good for you. But the reason those longer cues fail is still because they're not Red Book compliant.
Because the one for CD/CD-image works just fine within 99 minutes in EAC.
I'm aware they are not red book compliant, if I had more than 99 tracks, but below 99 minutes, I would use subindices of TRACK 99 and yet other programs are able to push it over that limit.
Because the one for CD/CD-image works just fine within 99 minutes in EAC.
But it doesn't work when the tracks total to more than 99 minutes. If you come up with a workflow to convert tracks in any format to your target format, then you can rip tracks from CDs, rip tracks from DVDs, and download tracks from the internet and use one workflow to convert tracks from all three sources to your target format.
I'm aware they are not red book compliant, if I had more than 99 tracks, but below 99 minutes, I would use subindices of TRACK 99 and yet other programs are able to push it over that limit.
If you stop using tools that expect Red Book compliance, you don't have to deal with these limits.
Because the one for CD/CD-image works just fine within 99 minutes in EAC.
But it doesn't work when the tracks total to more than 99 minutes. If you come up with a workflow to convert tracks in any format to your target format, then you can rip tracks from CDs, rip tracks from DVDs, and download tracks from the internet and use one workflow to convert tracks from all three sources to your target format.
I'm aware they are not red book compliant, if I had more than 99 tracks, but below 99 minutes, I would use subindices of TRACK 99 and yet other programs are able to push it over that limit.
If you stop using tools that expect Red Book compliance, you don't have to deal with these limits.
If there is a program with EAC functionality that also does DVDs and BDs, outputs log, has functionality to compare those against databases, that would be ideal.
As I mentioned, CueTools does handle longer cues, previous versions didn't even have the cap the current version has, which is why I'm investigating earlier versions to check if there is a version that can pull it off and still have the functionalities I need.
If there is a program with EAC functionality that also does DVDs and BDs, outputs log, has functionality to compare those against databases, that would be ideal.
But outputting logs and comparing against databases is only necessary for CD audio. DVDs and BDs have sufficient error detection/correction built in that all rips are guaranteed to be accurate. If you're concerned about file corruption after you rip the audio, calculate and store checksums (or use a format with built-in checksums such as FLAC or WavPack).
If there is a program with EAC functionality that also does DVDs and BDs, outputs log, has functionality to compare those against databases, that would be ideal.
But outputting logs and comparing against databases is only necessary for CD audio. DVDs and BDs have sufficient error detection/correction built in that all rips are guaranteed to be accurate. If you're concerned about file corruption after you rip the audio, calculate and store checksums (or use a format with built-in checksums such as FLAC or WavPack).
Theoretically CD format also have some form of error correction.
Theoretically CD format also have some form of error correction.
It was usable only when playing CDs in CD players, and not at all when ripping audio. There was only one CD drive, made by Yamaha (or Pioneer?), which would utilize that method of reading if ripping would fail, and I really don't know how it fared. Noone is talking about it, so I guess "too little, too late" from them.
Theoretically CD format also have some form of error correction.
It does. The problem is what happens when an error is big enough that the error correction can't fix it: some CD drives will fill in the missing audio with guesses instead of reporting the error. This problem is specific to audio CDs; it can't happen with DVDs, BDs, or most data CDs.
Theoretically CD format also have some form of error correction.
It does. The problem is what happens when an error is big enough that the error correction can't fix it: some CD drives will fill in the missing audio with guesses instead of reporting the error. This problem is specific to audio CDs; it can't happen with DVDs, BDs, or most data CDs.
Logical. But still EAC doesn't support DVDs/BDs, so I use different program.
Exactly. That's the same reason why you need a different program for files downloaded from the internet.
Exactly. That's the same reason why you need a different program for files downloaded from the internet.
Maybe, but so far if they were 16/44,1 it was enough to generate a cuefile for them and mount it and EAC would work with it.
Except when it doesn't.
And even when it does work, it modifies the audio to meet the limitations of the Red Book standard.
Except when it doesn't.
And even when it does work, it modifies the audio to meet the limitations of the Red Book standard.
What exact modifications does it perform? Other than padding to finish on CD frame?
Just the padding, if the bit depth and sample rate is already correct. But I thought you wanted to archive your audio? Any modification is counter to that goal.
Just the padding, if the bit depth and sample rate is already correct. But I thought you wanted to archive your audio? Any modification is counter to that goal.
Achive a digital download with EAC? I wanted to get the end result as with my usual workflow generating files for daily use, I archive bandcamp downloads as the zip it came in on external memory storage units. The only instance I use EAC for archiving is ripping CDs and especially CD-Rs to image+cue in case the CD-R rots and that can happen immidiately. I once got a fresh release from the band, replicated in by a renowned company and it had read errors from the start.
Then... what are you doing with EAC when the bandcamp download is already split into separate tracks? Transcoding? You can do that with a script. And the script will work with tracks ripped from CDs and DVDs and BDs too!
Then... what are you doing with EAC when the bandcamp download is already split into separate tracks? Transcoding? You can do that with a script. And the script will work with tracks ripped from CDs and DVDs and BDs too!
Processing them as if it was a CD to get the same result and workflow as with physical CDs finished with a log.
DVDae already comes with tools to provide me with desired end product.
Processing them as if it was a CD to get the same result and workflow as with physical CDs finished with a log.
And.. what is the result you want? Writing a script that spits out a log with the audio checksums is easy enough; just about everything else EAC logs is irrelevant to converting files between formats.
Processing them as if it was a CD to get the same result and workflow as with physical CDs finished with a log.
And.. what is the result you want? Writing a script that spits out a log with the audio checksums is easy enough; just about everything else EAC logs is irrelevant to converting files between formats.
The result I want is the same result I would get from ripping a physical CD with EAC including the stuff irrelevant to you.
The result I want is the same result I would get from ripping a physical CD with EAC including the stuff irrelevant to you.
I meant, like, which codec and what kind of tags and stuff. But please, explain to me how each of the items in the EAC log are relevant to you.
The result I want is the same result I would get from ripping a physical CD with EAC including the stuff irrelevant to you.
I meant, like, which codec and what kind of tags and stuff. But please, explain to me how each of the items in the EAC log are relevant to you.
The codec is irrelevant, the tags are updated in the player of my choosing after wards anyway including the subdirectory structure.
They are relevant to me, because I preffer them there to mimic the EAC log for a physical disc.
The codec is irrelevant,
It sounds like the codec is the only part that matters, since you're only using EAC to convert the audio to that codec and generate a log file.
They are relevant to me, because I preffer them there to mimic the EAC log for a physical disc.
Yes, but what in the log do you actually look for when checking to see if everything was done correctly?
The codec is irrelevant,
It sounds like the codec is the only part that matters, since you're only using EAC to convert the audio to that codec and generate a log file.
They are relevant to me, because I preffer them there to mimic the EAC log for a physical disc.
Yes, but what in the log do you actually look for when checking to see if everything was done correctly?
That is irrelevant to this discussion, the codec can be sbstituted with any codec and any settings.
The presence of informations that are traditionally in the EAC log without errors reported.
Yes, but what in the log do you actually look for when checking to see if everything was done correctly?
The presence of informations that are traditionally in the EAC log without errors reported.
?
That was not an answer. But anyawy, you would get:
* EAC version. Don't know why you need that, you don't use EAC to obtain the data.
* Date. Don't know why you need that, it is going to be wrong.
* Drive. Don't know why you need that, it is going to be wrong.
* Drive settings. Don't know why you need that, they are going to be wrong.
* Output format. Don't know why you need that, you know it already from the filetype.
* TOC. Don't know why you need that, it is going to be wrong.
What else? AccurateRip information that isn't applicable? CRCs that verify that if you read the same file twice it will still be the same file?
Yes.
MOD Edit: Removed multiple instances of quoted text
So, what you really "need" is a random EAC log and then a text processing script that takes the .cue and writes into the file
* the TOC table with rounded-off times or maybe even with long enough fractions of a second to be correct
* some bogus track information with arbitrary CRCs (say, 000000)
?
So, what you really "need" is a random EAC log and then a text processing script that takes the .cue and writes into the file
* the TOC table with rounded-off times or maybe even with long enough fractions of a second to be correct
* some bogus track information with arbitrary CRCs (say, 000000)
?
Ideally I need EAC, or CueTools to process the files in the firta place, or software to perform similar taskthat will output EAC like logs with as many informations similar to EAC as are used in the settings for said program.
informations
mis-informations.
informations
mis-informations.
"data" then. Semantics.
The point is that since
* it is not going to be correct
* you are not going to use it for anything, at least not for anything that needs it to be correct
then you can just generate a faux log by a text manipulation tool. It is going to include wrong statements that you are not going to use, so why care?
If you even insist on the audio CRCs, you can employ https://github.com/leo-bogert/eac-crc .
The point is that since
* it is not going to be correct
* you are not going to use it for anything, at least not for anything that needs it to be correct
then you can just generate a faux log by a text manipulation tool. It is going to include wrong statements that you are not going to use, so why care?
If you even insist on the audio CRCs, you can employ https://github.com/leo-bogert/eac-crc .
Why do people collect sealed and graded baseball cards? BEcause the want to. Same here.
Why do people collect sealed and graded baseball cards? BEcause the want to. Same here.
Incorrect comparison. All physical objects have value on their own. Even trash has value, because it can be recycled into something useful. Unlike text file with meaninglesss useless data, which has absolutely no value.
Why do people collect sealed and graded baseball cards? BEcause the want to. Same here.
Incorrect comparison. All physical objects have value on their own. Even trash has value, because it can be recycled into something useful. Unlike text file with meaninglesss useless data, which has absolutely no value.
I do realize that files have no inherent value and yet they do have worth, otherwise people wouldn't be charging money for downloads i the first place, be it stock images on getty, music files on bandcamp, software, or ppv videos.
So while I appreciate your insights, they are less than relevant to my original inquiry, so if you sticked to the topic, or provide a solution I would appreciate it even more.
The point is that since
* it is not going to be correct
* you are not going to use it for anything, at least not for anything that needs it to be correct
then you can just generate a faux log by a text manipulation tool. It is going to include wrong statements that you are not going to use, so why care?
If you even insist on the audio CRCs, you can employ https://github.com/leo-bogert/eac-crc .
Why do people collect sealed and graded baseball cards? BEcause the want to. Same here.
I think it would be more fair to compare this to special baseball cards in a larger-than-usual size, custom printed in one copy at your order.
And the "error", as you prefer to call it, being that you cannot get those without paying to get them customized.
That is irrelevant to this discussion, the codec can be sbstituted with any codec and any settings.
Now I'm really curious why you insist on keeping your preferred codec and settings a secret. But you're right, the codec itself isn't too important.
The presence of informations that are traditionally in the EAC log without errors reported.
So it's perfectly fine for the information to be wrong as long as it's there? Why bother having that information in the first place, then? If you only care about whether any errors that occurred, it's pretty easy to add error handling to a format conversion script.
So while I appreciate your insights, they are less than relevant to my original inquiry, so if you sticked to the topic, or provide a solution I would appreciate it even more.
But this is just beating around the bush. You got your answer multiple times, you decided you didn't like it so this convo goes on and on. Please, end the topic, stop responding. No software know to us will do what you want it to do for simple reason: the thing you want to do is not done the way you want it be done. Like cutting wood with kitchen knife, you can do it, yeah, but there are better tools for that for more than one reason, and there are reasons why we don't do it with kitchen knives.
That is irrelevant to this discussion, the codec can be sbstituted with any codec and any settings.
Now I'm really curious why you insist on keeping your preferred codec and settings a secret. But you're right, the codec itself isn't too important.
The presence of informations that are traditionally in the EAC log without errors reported.
So it's perfectly fine for the information to be wrong as long as it's there? Why bother having that information in the first place, then? If you only care about whether any errors that occurred, it's pretty easy to add error handling to a format conversion script.
The encoder and settings are not relevant to the inqiury, it can be swapped at any time for another encoder.
How will the information be wrong, if those will be the settings used.
So while I appreciate your insights, they are less than relevant to my original inquiry, so if you sticked to the topic, or provide a solution I would appreciate it even more.
But this is just beating around the bush. You got your answer multiple times, you decided you didn't like it so this convo goes on and on. Please, end the topic, stop responding. No software know to us will do what you want it to do for simple reason: the thing you want to do is not done the way you want it be done. Like cutting wood with kitchen knife, you can do it, yeah, but there are better tools for that for more than one reason, and there are reasons why we don't do it with kitchen knives.
Suggesting I don't do something, or use different software does not answer my inquiry, which was specifically "how to get rid of the error and have the specific software I'm using to carry on, without compromising the structure of the cue, or any other part of my workflow". I'm not interested in any toold you deem to be better. CueTools 1.9.1 processed the entire cue to tracks, so this is doable, which means it can be programmed into newer CueTools releases, which means somewhere along the updates the specific setting got capped to not allow more than certain amount, currently reported as ~140 minutes. So if there is no software known to you that can achieve what I need, then you don't know the answer to inquiry, therefore all yout input is offtopic, so please stop responding with sentences completely irrelevant to my inquiry, it's a waste of your time then.
How will the information be wrong, if those will be the settings used.
Don't you even read replies?
my inquiry, which was specifically "how to get rid of the error
... no, you don't.
What is with the AR database? Would this crap enter when pseudo ripped from a virtual drive?
There would need to be 2 or more people with, eh, the same workflow.
Not gonna happen.
And even if that happened twice, nobody else would you ever encounter those AR hits in this particular case.
Worse are those cases where you buy files that are ripped with errors from an actual CD. At least dBpoweramp tries to protect against submitting from virtual drives that mis-identify as actual drives - I don't know what EAC does, but in the very least it is possible to take some such measures. Also if a virtual drive identifies as such, the AccurateRip database will know, and results from doubtful drives are purged every now and then. Not saying it is fool-proof.
Thanks. One rip done with EAC and one in CUETools may be enough then.
Maybe for the CUETools database. I don't know about AccurateRip:
* Does CUETools even submit to the AccurateRip database? Anyway, just repeat the question with "EAC and dBpoweramp" instead.
* For that, I don't know: but IIRC dBpoweramp (the application) identifies the system configuration, so if you have a computer with two drives, use the first to rip with dBp, uninstall dBp completely and reinstall it and rip with the other drive, two identical won't count.
I don't know if EAC uses the same. (I'd be mildly surprised if they don't.)
And even if that happened twice, nobody else would you ever encounter those AR hits in this particular case.
Worse are those cases where you buy files that are ripped with errors from an actual CD. At least dBpoweramp tries to protect against submitting from virtual drives that mis-identify as actual drives - I don't know what EAC does, but in the very least it is possible to take some such measures. Also if a virtual drive identifies as such, the AccurateRip database will know, and results from doubtful drives are purged every now and then. Not saying it is fool-proof.
Virtual drives are presented as suc in the EAC log. It's also unlikely that enyone else will have the same workflow, so in worst case scenario there will be an unusable entry in the database that will veryfy against itself in case I need to reprocess anything in the future, but if the records are purged periodically then there won't be anything to verify against.
* Does CUETools even submit to the AccurateRip database? Anyway, just repeat the question with "EAC and dBpoweramp" instead.
IIRC CUETools can only compare your rip to existing AR entries. It cannot submit new results.
Still CUETools db may store some from EAC with plugin or CUETools itself.
How will the information be wrong, if those will be the settings used.
Because you're converting your downloaded files from one format to another, not ripping a CD.
You need a new workflow for your downloaded files that does not involve EAC or any virtual CDs. You refuse to use any new workflow that doesn't produce a log file. So, what information do you need to see in a log file to be convinced that the new workflow without EAC is working correctly?
In fairness to the OP he's never stated that the convoluted act of taking downloaded files, mounting them as an image to then just turn them back into individual files offers any benefit, it just silences the voices in his head from his OCD; he literally just wants a text file that looks similar to all the other text files (from actual CD rips) to sit alongside the music. Please stop trying to understand his "logic" and workflow, we all know it makes no sense but that doesn't matter to him.
With regards to AccurateRip submissions, virtual drive submissions are excluded as are any real submissions from that user as noted here (https://hydrogenaud.io/index.php/topic,71338.msg628751.html#msg628751), that's why they recommended CUETools for splitting/verifying from anything other than actual CDs.
In fairness to the OP he's never stated that the convoluted act of taking downloaded files, mounting them as an image to then just turn them back into individual files offers any benefit, it just silences the voices in his head from his OCD; he literally just wants a text file that looks similar to all the other text files (from actual CD rips) to sit alongside the music. Please stop trying to understand his "logic" and workflow, we all know it makes no sense but that doesn't matter to him.
With regards to AccurateRip submissions, virtual drive submissions are excluded as are any real submissions from that user as noted here (https://hydrogenaud.io/index.php/topic,71338.msg628751.html#msg628751), that's why they recommended CUETools for splitting/verifying from anything other than actual CDs.
This pretty much sums up my approach.
So you can exclude submissions from certain computer addresses including real CDs so that rips done by specific computer's owner are not stored in the db?
So you can exclude submissions from certain computer addresses including real CDs so that rips done by specific computer's owner are not stored in the db?
I have no idea what level they block at but would assume it's either machine or EAC/dBpoweramp instance. I've never tried to look at the traffic going back to AccurateRip but I don't think it's secure so you can probably see what's being sent, although looking at the EAC AccurateRip submission screen it contains a string at the bottom labelled Computer, so I assume it's that, although I don't know what it's derived from.
So you can exclude submissions from certain computer addresses including real CDs so that rips done by specific computer's owner are not stored in the db?
I have no idea what level they block at but would assume it's either machine or EAC/dBpoweramp instance. I've never tried to look at the traffic going back to AccurateRip but I don't think it's secure so you can probably see what's being sent, although looking at the EAC AccurateRip submission screen it contains a string at the bottom labelled Computer, so I assume it's that, although I don't know what it's derived from.
Yeah, if it's useful to them.
In fairness to the OP he's never stated that the convoluted act of taking downloaded files, mounting them as an image to then just turn them back into individual files offers any benefit, it just silences the voices in his head from his OCD;
I'll be straight: there is another possible reason, but the poster is not being obsessive, but just is exceptionally careful of not violating the TOS. And the mere fact of wanting to falsify EAC/AccurateRip results to facilitate is just...disappointing. Though not unexpected especially with todays standards...
I thought cred was earnt, not stolen. I'll just leave at that. ::)
In fairness to the OP he's never stated that the convoluted act of taking downloaded files, mounting them as an image to then just turn them back into individual files offers any benefit, it just silences the voices in his head from his OCD;
I'll be straight: there is another possible reason, but the poster is not being obsessive, but just is exceptionally careful of not violating the TOS. And the mere fact of wanting to falsify EAC/AccurateRip results to facilitate is just...disappointing. Though not unexpected especially with todays standards...
I thought cred was earnt, not stolen. I'll just leave at that. ::)
Believe me, I am not excepttionally careful, in fact I had been temporarily banned on multiple occasions on various databases and fb groups for being very OCD and some admins thought wat you were thinking, but after explaining my condition they would usually understand that they assumed incorrectly.
What today standards?
AR will be purging the results either way, so it's only for my othereise useless to anyone else 1s and 0s encoded in an artificial log file.
What would I possibly gain, if I was operating under your assumed pretenses?
OK, problem solved, the latest CueTools works fine, the option that must be turned off to not trigger the "Invalid stride" is "Verify using CTDB". The TOC is written to separate file however.