See: http://calonet.org/eac for a guide to the proper settings in EAC



The should be no issues if you have the folder settings correct. My problem was I didn't fully read the help behind the "?" buttons.
See the first quoted conversation in my most recent post [two above this one].

Yes, I read that. But I have my base directory as

D:\Backup\CDs

The name scheme is %I\%A\%C

So when AutoFLAC rips and converts the files, it put them in

D:\Backup\CDS\Genre\Artist\Album

But the CUE files is always saved in

D:\Backup\CDs

Is there a way to save them where the files are saved, or is this a bug?


ALSO, The link you posted has some outdated EAC screenshots I believe. Some of those options arent listed in the latest version I downloaded.

Base Directory in AutoFlac & EAC should match. Sounds like you have that correct.

However, it sounds like you have the name scheme wrong. They MUST match EXCEPT don't put the file naming format in AutoFlac. In your case, it should be:
%I\%A\%C in AutoFlac
%I\%A\%C\%N - %T in EAC [or whatever your file naming scheme is]

Im confused. In the NAME SCHEME filed in AutoFLAC, I have %I\%A\%C. This is correct or incorrect?


ALSO, regarding my quesiton earlier. Does it sound right that it only took 4-5 minutes to rip and convert a CD?

FLAC compression at standard settings should be, on contemporary processors, about as fast or faster as audio ripping can be performed on contemporary optical drives. In other words, yes, it sounds right.

-brendan

Thanks.

Another question. Does multitasking while a cd is ripped/encoded have any effect on quality, or should I be doing other stuff while AutoFLAC is running?

I thinkthat's really two separate issues:

1. Do AutoFLAC and the external routines it calls care? I don't think so, but I have to review the code to see if any assumptions are made about which windows are in front. One thing I do know is that it does assume only one instance of EAC is running, as finds it by window title.

2. Do EAC's extraction routines and/or the IO layers care? That I am less sure about. You certainly wouldn't want to do certain things such heavy disk IO...or CPU intensive tasks at high task priority that prevents EAC from responding in a timely manner. Doing so might interfere with the ability to stream the audio data uninterrupted to EAC. I doubt it is nearly as sensitive as cd *burning* programs have been, however.

In other words my answer is a wishy-washy: only experimentation will really answer it.

-brendan

Yes.

But in EAC Options [The EAC program itself, not the AutoFlac pop-up window] under the "Filename" tab, it should say %I\%A\%C\%N - %T. The path portion [%I\%A\%C] in EAC MUST MATCH AutoFlac. Then the file name option [%N - %T] after the path in EAC ONLY, as in %I\%A\%C\%N - %T.




No it doesn't, unless you are possibly ripping in Burst Mode or have your cache settings incorrect. In EAC, go to Drive Options [F10] and then Extraction Method. Your settings should be "Secure Mode" and then check "Drive has 'Accurate Stream' feature" and "Drive Caches audio data." Those are the ONLY boxes that should be checked on that tab.

These are my settings. Whats the average time it takes to perform these actions?

UNCHECK "Drive is capable of retrieving C2 information." Even if the drive is capable, EAC does not correctly handle the information.
CHECK "Drive caches audio data." We WANT the drive to cache the data, as opposed to the software.

I do not have [nor do I want to have] my settings your present way, so I can't say how long it takes. However, if the software is caching the audio, I would have to say it would be faster than if the drive did it.

In lossless trading circles, the magic sentence we want to see in the log is:
plus 'Test & Copy' which I have explained in an earlier post. These settings assure to the highest degree of probablility of an accurate copy of the original disc, which is why we use EAC in the first place, right?

Sorry I've been gone so long. Life occasionally gets in the way. Let me try to catch up on a few posts. :-)

bhoar, I'm going to have to address your posts separately. You've apparently been busy. Give me a couple days to try to get back into the swing of things.


Then it's an issue with AutoFLAC trying to match up with EAC's undocumented renaming scheme. I'll experiment and try to figure out how to fix it.


Good deal. The version on the website now supersedes the beta, so as long as that works for you you're good to go.


Thanks for reporting this. As I said, I attempted to explain it, but even as I wrote it I had doubts that it'd be obvious. I'll work on a better method for this, or improved documentation, in the next release.


I'll add an option for this in the next version. This would also apply to the variable naming scheme functionality, so I guess I should finish the job.


Why would you want to keep the original CUE sheet in addition to the one converted by AutoFLAC? It's the exact same, just with the filename extensions renamed to .flac. It'd be easy to have AutoFLAC copy over the original .wav version in addition, but I'm not seeing the benefit. Can you explain?


Ok, I gotcha now. Until EAC adds support for this, I'll just gray out the T&C option in AutoFLAC if image mode is selected.


Like I said, I'll work on this some more for the next release. As I'm sure you're aware, this is the first release that includes variable naming support, so it's likely to have some rough edges. You've obviously already found a couple of them.


I can explore that, but I'm a bit hesitant about trying to fully automate it. There are two main reasons the manual step in between is currently required:

1. Given that we're talking about burning instead of ripping, I'd rather the user have the opportunity to verify that all is correct before the disc starts burning. Otherwise, errors could be introduced, which in the best case would cost money and time to reburn the CD-Rs, and in the worst case would would not even be noticed (until you try to play back the CD at some later date).

2. A lot of CDs have data tracks along with the audio. If I'm burning one of those, then I'll want to include the data portion as well. EAC provides the option to either close the disc or leave the session open. In order to burn that data track, the audio session must be left open. This requires manual intervention.

Beyond that, it'd take a bit of time to code this properly and account for potential error messages. In this case, the time and risk involved in implementing the feature seems to outweigh the potential benefits. If this proves to be a popular request then I'll certainly look into it, but at this time it's not on my todo list.


audiomonkeyboy, the documentation for this feature is somewhat poorly written at this time. I apologize for that. To set a baseline, please set AutoFLAC and EAC to this:

AutoFLAC:
Base directory - D:\Backup\CDs
Name scheme - %I\%A\%C
Image scheme - %A - %C

EAC:
Filename, Naming scheme - %I\%A\%C\%N-%T
Filename, Various artist naming scheme - %I\Various Artists\%C\%N-%A - %T

These are the default settings, as documented in the AutoFLAC readme. Using these settings, tracks should be ripped like so:
D:\Backup\CDs\Progressive\Dream Theater\Octavarium\01-The Root of All Evil.flac

CUE sheets should also be properly copied over:
D:\Backup\CDs\Progressive\Dream Theater\Octavarium\00-Octavarium.flac

That should get you started. Once its working with these settings, read the help info provided by the ? button next to the variable naming fields and experiment with other settings if you wish. If these settings do NOT work, however, please let me know.

RolloTomasi, thanks for helping out with this while I've been away.


bhoar and RolloTomasi both did a great job answering this question, but I figure I'll throw in my two cents as well. Assuming you have a decently fast system, then yes, you should be able to multitask while AutoFLAC is running. The conversion from WAV to FLAC will not be affected at all. The only real concern is the process of ripping the tracks from your CD to WAV files. Assuming you're not trying to access the CD at the same time you're ripping it, doing anything that's really processor intensive (eg, playing a 3D game), or doing anything really I/O intensive (eg, defragmenting your hard drive), then you should be fine.

I routinely multitask on my system, and haven't yet had a problem (that I noticed, anyway ). If you have a doubt, though, then it's certainly safer to leave it alone.

Thanks for that info RolloTomasi. Now my log files state

Read mode : Secure with NO C2, accurate stream, disable cache

Im trying to get a better understanding of the disable cache setting. When its off, you state the drive is caching. What cache is this? I thought cache is temporary data waiting to be transferred to the program (EAC).

Please explain, I want to learn

No hurry. I put my todo/tofix list aside for my changes, since don't want to get so far afield that I don't get a chance for your opinion before comitting in a bad direction. As it is now, the no/multi FreeDB entries issue hasn't been addressed

In the meantime, I've been using AutoIT for several other fun projects*. I have AutoFLAC and REACT to thank for that.

-brendan

* the usual gui-based app automation, some networking foo for work (grumble, datacenter ignoring outages, grumble), WMI experiments, serial device control, even a couple with SPTI (scsi passthrough) fun (most for my multi-robot ripping project).

Remember, the goal with Test & Copy is to rip two identical files, with two identical CRC's to insure to the highest degree that the files are accurate copies of the original.

The way I have heard it explained, if the software does the caching, EAC uses the cache as the secondary rip, and ends up comparing the file with itself. That's why the speed is so vastly improved.

Read this: http://www.exactaudiocopy.de/eac3.html
and this: http://www.digital-inn.de/exact-audio-copy...highlight=cache



For the person you are trading with that does not use AutoFlac. The write mode works so well, I don't understand why someone wouldn't use it, but if they don't know about it, then I guess they wouldn't use it. OTOH, since WAV cue support was added to this version, is there really a need for a FLAC cue?

Yes, it's still needed. The reason why it does this is so that the cuesheet actually points to real files. After the WAVs have been converted to FLACs, they're deleted. So why would you want your cuesheet to point to non-existent files? If you were to try to load a cuesheet referencing the original WAVs into foobar2000, for example, it would fail, because the files do not exist.

As for trading with other people, I'm not going to really get into that topic, but in order for the cuesheet to be at all useful, it has to match the filenames that actually exist. So, if I have a collection of FLACs, the cuesheet must match the filenames. Otherwise, I can't do anything with it. If I want to burn that collection of FLACs directly with EAC (or anything else that doesn't natively support FLAC), then I'd need to convert all of the FLACs to WAV, at which point I can easily do a search-and-replace in the cuesheet to renaming the extensions as well.

Like I said, it'd be easy to do, but I just don't think it makes sense.

I've got two CD drives on my machine I don't seem to be able to kick off a second AutoFlac correctly. More accurately, the seoncd AutoFlac won't kick off a second EAC. I can manually start two EACs and run extract/compress on the two drives manually though I'm not sure what effect that has on ripping.

The other obvious issue with that is that it won't run metaflac though I'm note entirely sure how much of an issue that really is (esp given that I'm ripping individual tracks rather than the entire image... of course this might only prove that I'm totally clueless regarding what metaflac does... I figured that since the tags were passed to flac, then metaflac was only sticking internal bookmarks into the image).

Anyway... is there a reason/solution for not being able to run two autoflac sessions concurrently?

Well, the reason is simply that AutoFLAC checks for a running instance of EAC and uses it if found. It'll only start a new instance if necessary.

Is there a solution? Not currently, at least not with AutoFLAC. I'm sure you could probably use EAC concurrently, though you would have to maintain a separate configuration for each (such as pointing to a different drive). I could look into this is it's really an issue, but there would be several technical challenges involved in making this work properly, and I think my time would be better spent tackling some of the more serious issues (such as the file naming problem that Cutestory previously mentioned).

Gotcha, thanks. This is just a matter of convenience... it's much easier to work around than the naming problem :-)

BTW... if I am ripping individual tracks, is there any value in my running metaflac? I thought metaflac would be used only to add internal seek points in this case (assumption is that FLAC adds the tags specified via the -T switches to the image). Does it also add the CUE sheet stuff? Not sure how much I care about that either.

Right, AutoFLAC interfaces with EAC by checking for windows that contain Exact Audio Copy, and will reuse an existing session if it exists. I wouldn't recommend trying to use two sessions of EAC at this juncture.

My own todo list contains what I think is the proper way to allow for multi use:

1. Do not reuse EAC instances, start one afresh for each AutoFLAC instance.
2. Keep track of which process uses which windows.
3. Pass the drive to use from AutoFLAC to EAC.
4. Somehow map AutoFLAC/standard drive letters (e.g. "D:") to EAC's command-line use of drive numbers (e.g. "2") - sort of annoying. Alternately, have AutoFLAC use EAC's drive list dropdown, which might be easier to map.
5. Address the fact that EAC tends to unnecessarily play with the registry values while running.
6. Example: address the fact that EAC always sets the registry to disable SPTI while running, resetting it back to the correct value upon close. This is for those users not using ASPI, such as myself.
7. Perhaps some sort of Load EAC Config support in AutoFLAC.

-brendan

When ripping individual tracks, metaflac.exe is used for the following two tasks:

Renumber track tags, if multi-disc mode enabled
Add ReplayGain info, if ReplayGain enabled

You are correct that flac,exe adds the tag information itself through the -T switches. Also, when ripping individual tracks, the CUE sheet is not embedded in any of them (doesn't make sense to, since it describes the full album). If you were to rip to an image, and enabled the embed cue option, then metaflac would be used to embed the cue sheet in the image.

I have a pretty simple question, I hope.

Just started ripping with AutoFlac and I have to say it rocks.

Ripping single image with embedded cue sheet. When I play the flac file back in Foobar 0.9.4.1 each and every track has the "Track Title" tag surrounded by single quotes, i.e. 'Strangers of the Heart'. It is only the track title which seems weird to me.

Now, I admit that I upgraded several pieces of the audio software pipeline at the same time, so it might be a Foobar issue. I would really like to avoid hand editing each track to remove the " ' " from the track titles. This is the only issue I've had with this great contribution to the community.

Is there some setting that can keep these apostrophes from appearing? Is this normal for single image files?

Btw, the .cue files look fine. No extra apostrophes there.

-Cal

I had to do some funky stuff to automate embedding the CUE sheet, and foobar2000 was actually the main application I used to test whether or not I did it correctly. Originally I figured that simply using the --import-cuesheet-from switch with metaflac would work fine, but all that seems to do is add breakpoints. If I then loaded the .flac image into foobar2000, it didn't read the track title information correctly.

foobar2000 itself is, of course, capable of reading/storing this information, as I had seen previously, so I edited the track titles myself, saved the result to a separate .flac iamge, and compared it against the original. In addition to adding the breakpoints, foobar2000 seems to store the entire CUE sheet as a tag, which it then uses for title information. I can't remember the details right now, but I know that replicating this behavior myself was a major pain because metaflac cannot import comments that span multiple lines. So, I had to jump through some more hoops to make this work correctly.

Of course, as I don't use embedded CUE sheets myself, it's certainly possible that I overlooked something. I'll try to look into this when I get a chance, but I'm currently focusing my time on some other projects, so can't commit to any timeframe as to when I'll be able to fix this (if it is indeed a problem with AutoFLAC).

with flac-1.1.3 (including the beta) you can import a file into a tag, e.g.

I understand completely. I was mostly just wanting to make for sure I wasn't doing anything incorrectly to cause the issue. It is a small hiccup in a huge project. Again, thanks for spending all the time on the scripts. They are most helpful.

-Cal

Burning with AutoFlac results in the Buffer bar in EAC staying flat (at least on my machine):



CD plays perfect though with no audible glitches or dropouts on my audio. Any information as to why the buffers "seems" to be disabled? Futhermore, write speed seems to change significantly: I have it set at 8x but it would go as high as 12 and drop below 4 within seconds.

i have error mesage like here
http://www.hydrogenaudio.org/forums/index....st&p=440275

but i am using english EAC

Have you had a chance to fix the EAC problem I've been having? I couldn't tell from the release notes.

I'm fairly sure that is an EAC issue. I've seen double filenames like that before. Try doing the same thing outside of AutoFlac to see if the double naming problem still occurs. It's also possible that it occurs only when you have EAC set up to create the directories, as opposed to doing it manually. Try to take all the variables out of the equation.

Here's the solution for the double file name. I found this on another forum.

EAC gets the artist name and track name if they are separated by "/" and not "-"

Go to "Database" -> "Transform Actual CD Information" -> "Transform '-' to '/' [ Artist / Title ]"

And everything will go right

Greetings, All. First time poster, so be gentle. Here's my problem. I am running EAC with AutoFLAC, getting my feet wet, trying to figure out all the (endless) ins and outs of it. Near as I can tell, I have it set up correctly, BUT--two odd things happen. I am trying to rip a CD of instrumental Christmas music. All set up, EAC pointing to FLAC, ripping compressed, etc. While it's ripping ("All tracks", not an image), AF pops up a little window after EVERY TRACK, basically telling me, "Hi, I just ripped a track, aren't you proud of me?" which I have to click on before it will proceed. This kind of kills the 'click and go to bed' ripping I'd like to do. ALSO-and this is annoying - I don't think it's compressing at all. The files (which, incidentally, are being saved w/o any metadata, for no reason I can determine) are saving with a *.wav extension, and are about 200+/-MB each. I can't figure out how to compare to the original CD files, because they are all coming up as *.cda (CD format, I know), and about 45KB each. Obviously, they're bigger than this, but I can't figure it.
HELP!!

Sorry I've been away for a while. I've been focusing on some other priorities. I'm still not at the point where I can begin working on the next version of this, but I wanted to answer some of the questions that have been raised.


Excellent! I'll upgrade to 1.1.3 with the next release, which should hopefully fix Calufraxis' problem (and make my own code simpler).


This is odd. AutoFLAC shouldn't interfere with EAC's burning mechanism at all. All it does is decode the files to WAV, rewrite the .cue sheet to reference the new WAV files, then loads the CUE sheet into EAC. From there, everything is handled by EAC directly.

Can anyone else confirm this issue?


Damn, will need to look into this further. Can you post a screenshot of EAC when this error occurs?


This is the filename issue, right? If so, then no, I have not spent any time working on a new version of AutoFLAC. This is still on my todo list, though.


This shouldn't happen. AutoFLAC should only display messages before you start ripping (the main GUI) and after ripping has completed (status message and prompt to rip again). There should absolutely be no prompts in between tracks. Could you please post a screenshot of this, or at least an exact description of the message?


If the files are named with a .wav extension, then you're correct, they're not being compressed at all. It doesn't sound like you're using AutoFLAC correctly. I'd suggest re-reading the Readme.txt file to make sure everything is configured correctly. If it still fails, please post step-by-step details on how you're trying to rip a CD. This will help me determine what's failing.

Will do. Thanks!

I'm back. No joy. Went through EAC and autoFLAC, made recommended settings and bupkus. Here's my process.
-Insert CD
-Fire up EAC
-Select drive
-Select all tracks (as opposed to image)
-Copy Selected Tracks (compressed)

~~~Here's where EAC pops up that little window. It says: Usage:AutoFLAC.exe {/write [album.cue]]
I HAD had EAC directed at autoFLAC.exe, which I think might avae been causing this. I REdirected it to flac.exe, and this seems to have gone away. BUT--I now get THIS:

The external comperssor returned an error!
Options : --alt-preset standard "G:\MUSIC-RIP\Ctmp7?!1!5.wav"
"G:\MUSIC-RIP\Ctmp7?!1!5.flac"

file : G:MUSIC-RIP\Celtic Christmas - A Celtic Carol - 01 - Track01.wav

And so on with consecutive track numberts until I got sick of it and cancelled the action.
I reiterate: HELP!!

UPDATE:
if I just drag and drop the files through FLAC Frontend, they compress fine. 20.6MB file down to about 9.1MB. Must be in my settings somewhere. Still HELP! I don't really want to have to rip and compress in two steps if I can avoid it.

I have done nothing special except installing EAC and installing AutoFlac. No pointing, no redirects, no nothing. You are making it way over complicated.

Insert CD
Fireup AutoFlac from the program group.

You will probably have to uninstall and reinstall both EAC and AutoFlac. Follow one of the online guides for setting up EAC. I recommend http://calonet.org/eac

Nitro, thanks so much for your work! I've already recommended this to several friends that are new to the world of .flac

Ok, I think you're doing this backwards. It sounds like you're trying to use EAC to rip the tracks and somehow point them to autoflac.exe. I'm not sure how exactly you've done that, but it won't work (obviously). You should be doing the opposite - firing up AutoFLAC, setting your options in the AutoFLAC GUI, and letting it manage EAC. The only times you should ever directly touch EAC is during the initial configuration (as defined in readme.txt) and to update track/album titles for each CD if the freedb lookup is incorrect. Everything else is controlled by AutoFLAC.

Try this instead:

• Re-read through readme.txt one more time and validate that the EAC settings are correctly set, particularly the "External Compression" page which specifies flac.exe as the external encoder.
• Save your configuration and completely exit both EAC and AutoFLAC.
• Run AutoFLAC. It'll automatically start EAC and prompt you to insert a CD.
• After the CD has been detected, the AutoFLAC GUI will display. Select "All Tracks", ensure that "Rip to image" is unchecked, then click OK. Do not change anything in EAC or use EAC to run any commands, as AutoFLAC will automatically run the appropriate commands.
• Wait for a few minutes until it finishes. AutoFLAC will display a message when it's finished, so, again, do not do anything in EAC.
• Choose to not burn another CD, which will cause AutoFLAC to exit EAC, then check the output. Did it give you .flac files or .wav files?

Btw, one other general forum tip: when you're quoting previous posts in your reply, please only include the relevant portion of the post rather than the entire thing. This helps make the thread much more readable, as well as speeds up page load time and server performance.


Yeah, that's kind of what I was thinking.

I have discovered a stupid user action that will break AutoFlac v1.2. Selecting Activate beginner mode, disable all advanced features on the Tools tab of the EAC Options Window will cause the following bit of AutoFlac code (line 297)



to select Action > Create CUE Sheet > Single WAV File... from the EAC menu instead of Action > Create CUE Sheet > Multiple WAV Files With Gaps...(Noncompliant). I am not certain about the exact consequences, but I am fairly sure that having an incorrectly formatted CUE sheet causes AutoFLAC to crash when the CUE sheet is used in Write mode.

Please note that deselecting Activate beginner mode, disable all advanced features in EAC doesn't necessarily correct the problem because EAC may not immediately update the Action > Create CUE Sheet submenu. Check to make sure that the third item on the submenu is Multiple WAV Files With Gaps...(Noncompliant). I had to stop and restart EAC to reset the menu. Many thanks to the Nitro32 and other contributors to AutoFLAC.

I have been having this EXACT SAME PROBLEM!!!! I tried to restore a CD and had managed to figure out how it was creating bad CUE sheets, but I couldn't figure out how to make things right.

Thanks for the fix. The AutoFLAC documentation needs to be updated to account for this.

I'm going to go try this out.

Hi, so I think I found a minor bug but one nonetheless, if in EAC "replace spaces with underscores" is checked and one is ripping to individual files and has the output cue option selected, the generated cuesheet looks for files with spaces not underscores, however interstingly enought the generated m3u has the correct filenames (I think this is because it is generated by EAC). However it may just be that im doing something wrong, but there appear to be no other errors.
regards
canadiandude

I just noticed this today. When ripping through AutoFlac, the log file does not show any gaps. Also, the EAC GUI is not showing them. AutoFlac'd EAC rip first goes through the gap detection, and are shown in the cue file, just not in the log. When ripping with EAC alone, the gaps are shown.

Has anyone else noticed this?

EDIT: Workaround. When AutoFlac opens EAC and you are reviewing the CDDB info, press F4 to detect gaps before continuing to the rip process. Gaps will appear in the log and GUI. Note that the lack of gap info in the log does not affect the rip or cue file in any way. This workaround only allows the gap details to appear in the log.

I just wanted to post a quick note and let everyone know that I haven't abandoned this forum. I've been working on a bunch of other projects for the last few months, and just haven't had any time to devote to AutoFLAC. I've been keeping up with the issues posted here, and they will be corrected (to the best of my ability) in the next working once I have a chance to work on it.

AndyBKK, RolloTomasi, and the others who've posted tips and workarounds recently - thanks for doing so, and helping out other users in my absence. I really do appreciate it. Hopefully it won't be too much longer before I can get back to this. It's a pretty fun project. :-)

Quick question. I have ripped almost 300 discs now with AutoFLAC. I have another 800 or so to go. I have listened back to the tracks and most sound right, however, there are some that sound to my ear like they aren't losslessly ripped. I am hoping that this is just paranoia on my part. I really don't want to do this again. There are also a few tracks tha almost sound to me like they have a slight distortion in their top end. Anyway, I know that this isn't autoflac's problem, but I just wanted to know two things.
1. How do I make suer that the format being ripped to is truly lossless. (( think I read somewhere that there is one kind of FLAC setting that isn't)
2. Is there any way to compare the flac to the wav other than visually comparing the two?

the only flac encoding option that is technically not lossless is --sector-align and you shouldn't be using that anywy for ripping CDs. I would get rid of it altogether except tapers use it a lot.


encode with -V. I always do. to really be thorough you'll have to rip one of the suspicious albums to wave, encode with flac with the same command line as usual, decode to wav again, and compare the 2 wavs with fb2k or some other tool.

Josh

Thank you for your help. I was able to compare files and it worked. One thing that I don't understand is how do I control any FLAC encoding options when I am using Autoflac? I know that I can change options in EAC if I am using it by itself, but I am under the assumption that with Autoflac, this won't change the settings.

AutoFlac does not control any of the encoding options. Those are all set from withing EAC's compression options [F11 > External Compression > Additional Command Line Options]. AutoFlac only automates the process.

Hi,

I began using AutoFLAC.

My main gripe is that after the ripping (to single image) is complete, I'll have to wait until the encoder finishes for AutoFLAC to request another CD, which pretty much ruins the "Auto" part, when trying to rip tens of CDs.

Is there a way for AutoFLAC request another CD as soon as the ripping process finishes (and not wait until the compression process finishes)?

Okay, Thanks for the info.
So then right now i have "--best -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" %s"
would I just add -v at the end or the beginning of the whole string?

This is actually how it worked originally. However, it caused a caused a couple issues here and there for some people (can't remember the details at this point, but I'm sure it's documented in this thread), so I changed it to wait for the entire process to complete. It now essentially takes the "better safe than sorry" approach. I understand your point, though, and may add an option to adjust this behavior in future versions.


That would do it, but you really wouldn't get any benefit from it. AutoFLAC is does not check for this output, so even in the unlikely event that it fails, AutoFLAC wouldn't report the failure.

I've actually looked into this in the past at the request of a couple people on the board, but I never could find any good way of doing file verification. It's largely a limitation of the interaction between AutoFLAC, EAC, and flac. I still have this on my todo list, though, so I'm certainly going to try to work it in to a future version.

Josh, since you seem to follow this thread, I'd like to talk with you briefly about this once I resume work on AutoFLAC. If I recall correctly (and my memory's admittedly hazy about this), I think the problem I was having is that I couldn't programmatically determine whether or not flac -v was successful. Perhaps you maybe be able to suggest an approach I hadn't thought of. You obviously have a bit more experience with flac. It'll be a little while before I'm able to work on it again, but I just thought I'd mention it while on the topic.

yeah, if verify ever fails, flac should return a non-zero exit code.

BTW just to make sure, the option is capital V ("-V", or "--verify" with 2 dashes is a little clearer). little v just shows the version.

Josh