Do you have the base directory set the same in both AutoFlac and EAC? That looks like the problem, since your naming schemes look good.

Took me a few tries to get the hang of it but am now happily ripping my multi-disc sets using AutoFLAC. Many of these are classical and I've not been able to figure out how to get the composer field propagated from freedb. Did I miss something?

--thanks

EAC doesn't know anything about the COMPOSER tag. Only ARTIST. As a result, AutoFLAC only applies the ARTIST tag. So, no, you're not missing anything, it just can't do what you want.

Hope this clears it up, though.

Question about error passing between EAC and AutoFLAC:

AutoFLAC finishes its job, ejects the CD, and pops up a dialog box saying: EAC detected possible errors in track(s): 7, 9, etc.

I browse the directory, look at the log file and see that track 7 looks perfect, track 9 is nearly so (but AccurateRip thinks all is well):

Peak level 60.9 %
Track quality 99.9 %
Copy CRC F9C31C32
Accurately ripped (confidence 11) [17B65A55]
Copy OK


If/when I re-rip suspect tracks (click OK, reinsert CD, highlight suspect tracks, re-run AutoFLAC choosing Individual Tracks instead of All Tracks) I get repeated reports of the same tracks (e.g. 77, 99, or other odd permutations.) Also frequently see old tracks appear after changing discs in a similar way. Seems like maybe a buffer isn't getting cleared after each run?

Are you using EAC v0.99? I haven't tried it with AutoFlac yet, personally. And is AutoFlac generating the error or EAC. 0.99 is still pre-beta, so that is probably the source of the error message.

This looks like a really useful utility, just what I've been looking for to speed up backing up my CDs. Unfortunately I've been playing with it for a couple of hours without getting it working properly, presumably because of naming issues.

I'm trying to rip to a single FLAC image with an embedded cue sheet.

Initially I tried setting image scheme in AutoFLAC to %A - %C/%A - %C and naming scheme in EAC to %A - %C/%N - %T, thinking that this would put each image in its own folder. Instead no sub folder was created, the files were just placed in the base directory. Only the FLAC image and log were generated, with (AutoFLAC) tagged on the end, no cue file was generated and embedded.

I tried putting back the standard naming scheme from the AutoFLAC readme file: %I\%A\%C\%N-%T but nothing changed, it just created the FLAC image and log as above.

The base directory is the same in both EAC and AutoFLAC and the files are created in the intended directory.

I'd be happy enough if the FLAC/log/cue were all created in the same directory, rather than subdirectories for each album, I assumed that'd make things simpler...

At the moment image scheme in AutoFLAC is %A - %C, while naming scheme is simply %N - %T in EAC, no sub directories are set in either. This time the cue is generated, but (AutoFLAC) is still tagged onto the end of the FLAC and log files, and it isn't added to the cue sheet's filename. Once renamed the cue works, but it isn't embedded in the FLAC image. This is the closest I've come to getting it to work as expected.

Any idea what I'm doing wrong?

Can anyone offer a naming configuration that works for images with embedded cue sheets?

Alternatively, is there another utility that's better suited for what I'm trying to accomplish?

Thanks.

Yes, v0.99pb3 (20070817 build)




AutoFlac is reporting strange track numbers, some of which seem related to prior jobs - perhaps it might be mis-parsing the EAC logfile?

I'm guessing here, but AutoFlac may not support 0.99, only 0.95. Try going back to 0.95 and see what happens.




Your problem is the naming scheme. In your first instance you have one too many occurances of "%A - %C" in the AutoFlac setting. In the second instance they are completely wrong.

Easy mistake.

See my post from March 22nd on page 10 of this thread. That should make it clear. I have the year in parentheses in that example, but you can remove it as long as you remove it in both places, AutoFlac and EAC.

And to my knowledge, you can't do embedded cues.

I am getting the following AutoIt error message:





Everything seems to burn OK and I have checked the directory names of all associated files but am at a loss as to what this means (besides no cue being generated).

naming scheme copied and pasted into Autoflac from EAC %I\%A\%C\%N-%T
EAC version V0.99 prebeta 3
Autoflac version 1.2
OS Windows 2000

Thanks for any assistance.

I assumed that a / could be put in the AutoFLAC setting to create a subdirectory for that particular rip. Presumably any directory naming has to be done in the EAC setting alone?



I did notice that post earlier and tried those settings, but nothing appeared to change. It still created the files in the base directory, with (AutoFLAC) tagged onto the end of the filenames (before .log and .flac), and no embedded cue sheet. Also, it only put the year in the cue sheet filename, not the FLAC and log files themselves.

Any idea why this isn't working?



It is an option in the AutoFLAC 1.2 GUI, under the "Create cue sheet" option.

I suppose I'll answer my own post.

I read earlier about not including the track names in the AutoFlac naming scheme. I changed the AutoFlac naming scheme (eliminating the track names) to %I\%A\%C\ while leaving the EAC scheme unchanged %I\%A\%C\%N-%T.

Now everything works fine.



NITRO322

1. Love your program but perhaps you could clarify the readme.txt outlining how naming schemes are correctly entered to preclude problems. This is the current readme.txt found under AutoFlac rip mode instructions:

Name scheme - Directory naming scheme for ripped tracks;
This must match the naming scheme used by EAC
Click the ? button for detailed information


For clarity, perhaps you could modify the second line to read:

Warning: You may have filenames in the EAC naming scheme. However, do not include file names in the AutoFlac naming scheme".


It's just too easy to copy and paste the naming schemes resulting in errors.


2. I also like the Multi disc option in AutoFLAC but find that I have multi disc sets with more than 9 discs. Any chance the entry field for this option could be widened to two characters instead of just the single digit?


3. A while back you mentioned about AutoFlac being able to write from cue sheets generated in EAC and not AutoFlac. Due to earlier problems, I have some good burns but without cue sheets written in AutoFlac. I subsequently generated cue sheets with EAC but unfortunately, I cannot use AutoFlac write mode to burn using these cue sheets. I have no problem burning with cue sheets generated with AutoFlac. Can AutoFlac generate just a cue sheet without an complete re rip of the original CD?


Thanks for your work. The popularity of AutoFlac will certainly grow as others become familiar with its capabilities.

I've never had a problem with EAC cues generated outside of AutoFlac. I'm am guessing that the error you receive is referring to a non existent file in line 7, or AutoFlac is not extracting at all, and likely both.

Look at the non-working cue in notepad. If there is a path reference to the file name, edit it out. The stated path does not refer to the proper location of the files. Here is the problem.

When you set up EAC for AutoFlac, you set up a folder that will always be used for ripping. EAC > EAC Options > Directories tab. For AutoFlac to work properly you must have a folder stated there.

When the AutoFlac ripping process begins, EAC generates a cue file, puts in in the Directory stated in the option, and the path statement is included in the file. However when the ripping process completes, the AutoFlac script moves the cue to the destination folder and edits the cue file, removing the path reference.

If you generate your cue file outside of AutoFlac, this directory information is left in the cue, and once you move the folder, this directory info stated in the cue is no longer valid, resulting in an error when you attempt to burn, whether using AutoFlac for burning or EAC alone.

If your are experiencing some other error, please go into more detail.

Rollo,

Thanks for the information. I am afraid that all I know about this subject I have learned by reading this forum. Your valuable input will provide me the guidance required to resolve the issues I am having. It might be after the holidays before I can get back to archiving my CDs but at least I now know what areas need refinement.

I am curious why with certain CDs, cue sheets are not generated with AutoFlac (yes the generate cue box is checked) after the rip/encode process is complete. Most complete properly with the cue sheet but every now and then there is a CD that when ripped/encoded produces no cue sheet. If all I need do is subsequently generate a cue sheet with EAC then nothing is really lost except the one step convenience.

Thanks again

hi nitro322,

thanks for this great FLAC utility! i have a question... is there a way to make autoFLAC write the cue sheets with underscores in the file names?

i set EAC to replace spaces with underscores, so the output file is
01-artist_name-song_name.flac
but in the cue sheet that autoFLAC generates, the file name is
01-artist name-song name.flac

this will obviously cause problems with burning int he future... is there a way to change the cue sheet output?

thanks again...

Hi,
I have a small prob (well not that small) with Autoflac.

When EAC is done ripping, Autoflac tells me at once that job's done, although it's not.
Waves haven't been compressed to flac.

What could be the problem?

Brief note up front:

Sorry I've been away for a while. As things go, I've had various other priorities in my life over the past year or so, and obviously AutoFLAC hasn't received much attention. I still don't have a great deal of time to devote to it, but I'm slowly making progress on a new version. I'm planning on reading back through this thread since the 1.2 release to make a todo list for various issues that need to be resolved, but if there are any pressing items that you'd like to see addressed please go ahead and post them. The 1.3 release probably won't be ready anytime soon, but the more I can plan up front the easier/quicker things will be.

Thanks.


I know, this can definitely use some clarification. It's been pointed out several times in the past and I do intend on fixing it, but AutoFLAC has been on the back burner for a while now.


Damn... 10+ discs is impressive. :-) Out of sheer curiosity, what are you ripping?

As for your request, I'll look into it and see if there's any easy way to do it. To be completely honest, given the extreme rarity of such a need, I'm not really willing to invest too much time in this, but I'll certainly check it out.


Hmm... I have two responses to this.

1. AutoFLAC should support non-AutoFLAC created CUE sheets. If that's not working, then you've either found a bug or are using a CUE format that I haven't seen (and therefore didn't include in AutoFLAC). Can you send me and example? I'll try to add support for it.

Edit - after typing the following paragraph, it occurred to me that trying to burn a multi-disc album that uses 3 digit track numbers in the file name but only 2 digit track numbers in the CUE file would probably cause this to fail. Is that perhaps what you're doing.

2. Using AutoFLAC to only create a CUE sheet doesn't make too much sense. It, itself, doesn't create the CUE sheet. It simply has EAC do it using the "Multiple WAV Files With Gaps" option, then rewrites it a bit to make it more appropriate for the FLACs. Primarily, this just involves renaming the extensions to .flac instead of .wav and renumbering the tracks if using the multidisc option. The CUE sheet can be generated easily enough by EAC directly, and the hand editing can also be done with search-and-replace if desired. And, since AutoFLAC supports generic EAC CUE sheets (or is supposed to), this is all optional anyway.


Weird. Again, this should just work, but there are some issues with special characters in filenames. I've ranted about this before, so you can search this thread for details, but if you have special characters in the album or artist name this may not behave correctly. Also, check the "Base directory" and see if the CUE file was created there but just not copied over properly.


Not currently, but I'll investigate adding it in the future.


I've actually recently seen this problem myself. EAC doesn't provide any way (as far as I've been able to tell) to definitively tell me when encoding is complete, so I'm using a rather ugly hack to figure this out. It's possible for the timing to work out such that AutoFLAC thinks encoding is complete, but in fact EAC has just completed one but not yet started the next. Fortunately this seems to be a fairly rare occurrence, but needless to say it can be quite frustrating when it surfaces.

The good news is that I've recently come across a CD that reliably repeats the problem. I'm working on a way to make this detection process much more reliable so that this won't be an issue in the future. So far I haven't made too much progress (unfortunately), but this is probably my top priority for the next release.

Can you regularly repeat this problem with a particular CD? or does it only happen randomly? If it's regular, would you perhaps be interested in testing a beta version (when I have it fixed, of course) to see if my fix resolves the problem for you as well? Please let me know.

Sweet. I hate to reply to myself, but I just found what seems to be a reliable way of detecting when EAC is truly finished encoding tracks. Out of the three CDs I had that exhibited this behavior, none appear to do so now.

So, at least on my system, this looks like it's fixed. :-)

Just wanted to post another short update.

On the cue files that do not work with AutoFlac, I'm gonna go out on a limb and say that if one were to open the CUE file in notepad, there is either a full path in front of the file name or the FLAC file names are different from those referenced in the CUE. [i.e. User Error] If the path doesn't exist, then AutoFlac won't extract it. Same thing if the actual FLAC file names are different from what is referred to in the CUE.

When this happens, the EAC CD-Writer will report an error. Simply go back to the files containing the original FLAC files, and manually extract them to WAV, using FlacFrontend, dBpowerAmp or similar program that you may happen to have. Move these WAVs to the AutoFlac folder [where the new CUE resides] and change the file names to match the CUE. You may also have to remove the path in the CUE file. This can be done from within EAC as well.

I have stated in a couple of posts that EAC v0.99 is not supported. That may very well be Nitro's official stance, but I can confidently state that AutoFlac does, in fact, work quite well with v0.99.

Yes, there was a problem with this code, nearly exactly what you described (though it was a variable and not a buffer that wasn't cleared). I've fixed that in the dev version.


This is correct. AutoFLAC reads the CUE sheet and determines what needs to be decoded based on the contents of the CUE sheet. If the CUE sheet does not reference the correct file names (whether using absolute or relative paths), then decoding will fail. The easiest solution is usually to just edit the CUE file and remove any hardcoded paths. If only the track name is specified, then both AutoFLAC and EAC assume that the audio files are in the same directory as the CUE sheet.


AutoFLAC 1.2 (the current version) was written and released before EAC 0.99 was released, so no, it's not officially supported. However, I recently began using it and it does indeed work pretty well. The only issue I've seen is that .log files are no longer properly renamed if the option to save LOG files is chosen and ripping individual tracks. This is because EAC changed both the name and directory to which the log file is written, so AutoFLAC can't find it. I've updated this in the dev version, which will fully support EAC 0.99 (though, because of this and potentially other issues, not 0.95).

Btw, I think I've said this in a previous post, but thank you so much for the time you've put in helping others in this thread. I obviously haven't been around too often for a while, but I've been checking in every couple of months or so and I've seen your numerous replies to questions posted in this thread. Thanks for providing better support than I have. :-)

You're welcome, Nitro. And, BTW, I just noticed the issue with renaming the v0.99 the log files. Really, a non-issue. It only fails to add the "00-" preceding the file name, and it must be EAC that now writes the log to the ripped folder, rather than the folder we have set in the 'Directories' tab. I never noticed until you brought this up.

Just a reminder for your dev version, please set up AutoFlac to "Detect Gaps" before calling the CUE generation. This will allow the gap information to appear in the log file.

How is this different than the creating the CUE sheet with the "Multiple WAV Files With Gaps" option? I've tested this pretty thoroughly, and using this option does allow me to create a darn near exact duplicate of the original CD, even including those with odd/complex pregaps. What will Detect Gaps do differently?

Note - not opposed to it, just want to understand. Thanks.

If one does not first detect gaps prior to initiating AutoFlac, the gap information does not appear in the log. It is still in the cue file, but not in the log. The resultant FLAC files are bit identical. The only difference is the log file.

For the hard-care perfectionists in the file-sharing world, this information is necessary. For example, if the log of a known CD does not contain any intermediate gap information, then this may indicate a CD-R rip [burned with Nero or another program without the use of a non-compliant cue].

OK, I gotcha now. I was focused on the .cue file, not the .log file. :-)

Many Jazz and Classical sets easily exceed 10+ dics, hence the request.




I did find an example where the 3 digit track numbers caused a problem. However, the bulk of my cue sheet difficulties were eventually traced to an incorrectly selected gap index/retrieval method (Gap Detection Tab under drive options in EAC).



Thanks for providing this information. It allowed me to better understand CUE sheets and to fix many of my CUE sheets which were not working properly.

Is there a fundamental difference in selecting the "Multiple WAV Files With Gaps" option over the "Multiple WAV Files With Corrected Gaps" option or even the "Current Gap Settings" option?

Wow, I thought I was the only one who noticed this.
I kept quiet and just did the gap detection manually before hitting OK on the AutoFLAC window.

I would also suggest a way of automating the writing of Album Artist tag to "Various Artist" on VA CDs.
Also, using the disc tags would be good too.
Not sure if that is possible but worth asking.

This old issue has been solved, BTW. Hans and I worked it out. :wave: It had to do with the contents of the CDRDAO subfolder. If you rename the EXE and DLL files to EX_ and DL_ respectively, the problem disappears.

Nice to see that's a known problem, and that it's your probably your top priority!

But after several trys, i'm afraid it's not a CD problem.
I can repeat this problem with every CD i have, even CDs that i succesfully ripped with autoflac in the past.

The only thing i see is that i was on Vista when it worked, and now i'm back on XP, it doesn't work anymore.

Is there ever going to be an update to AutoFLAC so it works with EAC 0.99?

It works fine with v0.99. I've been using it for a couple of months now. I may have stated earlier that it does not, but that was incorrect.

I'm having a strange issue with AutoFlac...

MY CUE sheet entries look like this: "FILE "-1 New Wave.wav" WAVE" insetad of "FILE "01 New Wave.wav" WAVE"

Any ideas?

Hi, thank you for making the program available. Great software. I am experiencing the following issue though I set up EAC and AutoFLAC according to the readme file.

When done with the flac conversion from wave, the cue file does not have (AutoFLAC) just before the dot designating the file extension, like the flac and log files do. Also, line 7 in the cue file lacks the (AutoFLAC) tag before .flac, so when trying to burn, the cue file cannot find the actual target flac file.

The cue file has the (AutoFLAC) tag a space before the file extension dot, but only through the extraction. When the flac file replaces the wave file at the end, the cue file loses the (AutoFLAC) at the end of the file name and also at the end of line 7 inside the cue file.

I have tried everything, but no solution. Everything is configured as in the readme for AutoFLAC.

I am also wondering why AutoFLAC appends that (AutoFLAC) tag to begin with, including parentheses, like that.

This is hapening when ripping all files as an image .

Thank you so much in advance.

I've never seen this happen. Does it happen when you rip individual files rather than an image? Does your naming scheme include 'AutoFLAC' anywhere, either in EAC or AutoFLAC itself?

Thank you very much for responding. It happens when ripping all files as an image in AutoFLAC, with making cue sheet selected. (not embedded)

EAC naming scheme: %I\%A\%C\%N-%T

EAC Various artists scheme: %I\Various Artists\%C\%N-%A - %T

AutoFLAC naming scheme: %I\%A\%C\

AutoFLAC image scheme: %A - %C

Naming schemes do not include AutoFLAC anywhere. Directories are the same in both EAC and AutoFLAC programs, otherwise the ripping would not even start. As far as I can tell, this is the setup according to the AutoFlac readme instructions, which I hope I followed to the letter.
The "(AutoFLAC)" gets appended only when ripping as an image is selected in AutoFLAC, with cue sheet selected. (not embedded).

The weirdest thing: cue file starts with "(AutoFLAC)" appended also, (including the parentheses, and while the wave files are still extracting) both in the cue file file name, before the dot for the file extension and inside the cue in line 7 just a space before the dot, but when the flacs are done and operations are complete only the log file and flac file have the "AutoFLAC" appended at the end, but not the cue file. In the end, the cue file loses the "(AutoFLAC)" tag, both in the file name and inside the cue sheet in line 7, making the cue file unusable to burn the flac. It works when adding in Notepad inside cue in line 7 "(AutoFLAC)", but it is rather annoying.

Thank you for your help.

I'm seeing the same thing when ripping to an image.

Does not happen when in track mdoe, but track mode messes up the CUE sheet by replacing the first number of the track number with a hyphen. (see my above post)

Any ideas on how to fix this?

Thanks for confirming what I reported. I do not get the hyphen in non-image mode, with all tracks selected, so my cue can be burned by Burrrn, Nero or AutoFLAC write mode just fine, but it is not read in Foobar (Unable to open item for playback (Error parsing cuesheet: invalid index list (line 21)), while it opens fine in Winamp, with individual track selection and browsing and playlist items working just fine. However, the edited cue in image mode can be burned fine and is also read by Foobar and Winamp and showing all tracks etc. As I mentioned above, the editing consists in adding "(AutoFLAC) at the end of the file name in line 7 inside the cue.

Since no one else has replied to my concerns anymore, I have decided to change my strategy to doing separate tracks with cue, instead of image with cue. There are no problems it seems with that approach, and of course in both cases I thoroughly studied these forums on EAC and AutoFlac and the proper naming strategies for both applications. Nevertheless, I would have appreciated a more lively contribution, especially from the more experienced members.

In any case, it appears doing individual tracks with cue is a much better approach, especially since EAC can still burn an exact CD copy, which can still be extracted again perfectly with AccurateRip. Meaning you extract individual tracks with cue in AutoFlac, then you get all tracks accurately ripped in the log, then you burn the CD with AutoFlac in burn mode(via EAC, not Nero or Burrrn or anything else), and then when you test-extract from that burnt CD again, you still get perfect rips from Accurate rip. But only if you burn from that cue sheet through AutoFlac/Eac. I have been getting flawless results with this approach.

The only problems that can occur(assuming naming conventions are the same in both programs), are usually due to illegal characters in the actual CD Title or CD Artist name in EAC(right at the top, in the middle), which usually become part of the folder name in Windows, which cannot have these characters under any circumstances. If this happens, then you will get weird things, like the lack of a cue file, or missing items, etc. You also must make sure the names there are not too long, and must weigh their length against the length of the individual track names, to avoid problems. Assuming naming conventions are identical, then virtually all problems can be traced back to illegal Windows characters or overly lengthy track names or Cd Title or CD Artist.

These are the illegal Windows folder characters:

/ ? < > \ : * | "


You will do perfectly keeping these things in mind.

I guess I helped myself.

But others won't have to go through this again.

P.S. If you still get some problems, then you can still adjust the cue file manually in Notepad, and you might have to edit both the track file name and its equivalent in the cue, to make sure they match.

That is all.

Au revoir.

Maybe this will spark some responses.


Oh, and one more thing. Illegal characters in the track names seem to be simply changed to a hyphen by EAC, and are not a problem and you do not need to edit them out, unless they are in the CD Title or CD Artist fields, which become the Windows folder name for the rip. Both freedb and gracenote and what have you all may have such characters in their info, so check carefully.

Let me know if you have anything else to add.

Plextus, vulc44n,

I'm not sure what's going on. I'll check it out when I get a chance and see if I can offer an explanation (and hopefully a workaround). If I can repeat it on my system, I'll also make sure it's fixed for the next version.

Hello nitro322, nice to meet you and many thanks for writing AutoFlac, such a wonderful and useful program, saving us all a lot of trouble digitizing our CD collection.

Thanks for touching base with us as I hope my latest feedback can clarify a few things, and especially since I do not intend to go back to the image-with-cue strategy, because I find it now less practical, and especially since a perfect copy of the original CD(that can be re-extracted and then verified with AccurateRip) can still be made from individual track with cue. At this point, I am really not attracted to the image approach, except for certain specific situations. I am also thinking that the hardware flac players are probably unable to read either the cue files or the images themselves, but rather only the individual flac files. Please someone correct me here if I am wrong, since it is only my hunch.

In any case, thanks so much for getting in touch here with us nitro322, and I really am grateful for this program. I have used extensively now and will continue to do so in the future. Looking forward for the next version and I appreciate your listening to our experiences with AutoFlac.

Regads.

Plextus.

I'll take the blame for that. I haven't been able to devote much time at all to AutoFLAC for quite a while now. Some of the others in the forum actually have been following this thread and replying where possible, which I greatly appreciate, but of course if there's a problem with the program then obviously it's the author's responsibility to address it.


I don't know that it's necessarily better, but personally it's my preferred approach, and as a result it'll likely be more "stable" as I can uncover and fix bugs during my own use of the program. Ripping to image files should work, however, and if there's a reported bug I'll definitely look into it (though, going back to that whole "no time" thing, it may be a while before I do).


This is a known problem. You can search the thread for previous rants on this topic if you want the details. I tried to work around it in the 1.2 release, but obviously failed. I'm going to try to figure out a better approach for the next release.


One thing to keep in mind where the image-based approach does have a distinct advantage is when dealing with CDs that contain audio data in the pregap. The individual track approach cannot currently handle these tracks.


Glad AutoFLAC has been useful.

Thanks for your feedback nitro and thank you so much for your time. Regarding the above, can we trust that EAC will reliably display such "hidden" tracks in red though, so we can know to do an image then?

Thanks.

It appears the download section of your website is down. Do you have an alternative download location?