Verify that the Artist and Album names displayed in EAC exactly match the Artist and Album folder names. Sometimes Windows/EAC will name the folder differently than what is displayed. This can happen if there's an "invalid" (according to Windows) character in the filename, such as a '/', or it can happen if there's a trailing space after the name (which is frustratingly difficult to troubleshoot, believe me).

I'd suggest that you copy/paste the artist name from EAC and Windows Explorer into notepad, one below the other, then repeat with the album name. Verify character by character that they match. This is most likely your problem.


I'm currently working on other projects at the moment, so no major features will be added anytime soon. I do still need to make a couple bug fixes, which I hope to do soon, but it'll be a maintanence release only. As for your specific requests:

A) This has been requested by a bunch of people, and while I'm not opposed to it, it would take a good bit of time to implement and test properly. I'd say this is on my long-term todo list, but I can't commit to any particular timeline for getting it done. AutoEAC already supports this, though, so if this is important to you I'd recommend you use that version.

B) I don't have any plans to add this capability. While I'm sure it would be convenient, the stated purpose of the program is to backup lossless copies. MP3, even if done as a duplicate, is simply outside of that scope and I'd rather not spend time implementing that functionality.

I think a better solution to this problem would be to use a script/program that can transcode your collection after the fact into any format you want. This way, as your musical needs or technical preferences change, it'd be very easy to simply delete the lossy copies and run the script again with different settings to create a new copy. I've already written such a script for my own collection, which I do plan on publishing to my software page after a few finishing touches, but it's designed for individual FLACs. I don't know how much work it'd be to modify it for FLAC images. I'm sure you can find other programs capable of doing this, though (foobar2000 comes to mind).

C) If you're talking about ripping to a FLAC image, then all hidden audio tracks will be included, even tracks hidden in track 01 index 00. If you choose to rip to individual tracks, then all hidden audio tracks except track 01 index 00 will be included. This is a technical limitation, though I'm trying to come up with a workaround for it.

Data tracks, however, cannot be embedded in a FLAC image. It's just not technically possible. If you prefer album images vs. individual tracks, then it may make sense to create an ISO image of the Data track vs. simply copying over the files like AutoFLAC does. Personally, I prefer having the individual files, as this makes it actually usable while sitting on my file server. However, if you want a true duplicate copy, an ISO image would be better, as you can ensure you maintain the volume title, etc.

ISO support, however, is another feature that I don't currently plan on adding to AutoFLAC. Think about it this way: if I was solely interested in making 100% accurate archive copies for no purpose other than to backup my CD collection, then I wouldn't even bother with AutoFLAC. I'd use CDRWin, or something similar, and make bit-by-bit images of the entire disc. This would be the most accurate solution to recreating identical copies, but I also want to be able to enjoy this material as well. If I'm giving up a couple hundred gigs of storage space, then I absolutely want to be able to browser through my collection and listen to any song or watch any bonus content that I'd like. With ISO or BIN/CUE images, that'd be simply impossible (or impractical at the very best).

Hope this helps.

Thank you for your response! I am stumped. I have verified the naming schemes letter for letter. Am I supposed to incluse the entire string in both? That is how it is right now.
naming scheme in EAC is: %I\%A\%Y\%C\%N-%T
naming scheme in AutoEAC is: %I\%A\%Y\%C\%N-%T

various artist naming scheme in EAC is: %I\Various Artists\%C\%N-%A - %T
various artist naming scheme in AutoEAC is %I\Various Artists\%C\%N-%A - %T

I checked for spaces as well. Thanks for your help here. I greatly appreciate it.

Don't verify the naming schemes (well, verify them, but that's not what I meant above), verify the actual names. Make sure that what's displayed in EAC (which is what AutoFLAC/AutoEAC expects) matches the folder names created for this album.

I'm sure this is User Error, but I'm getting the following error when running AutoEAC 1.04:


I'm getting FLACs, but ReplayGain is not being applied. The flac and metaflac executables are both in the same directory.

What have I done wrong? I'm sure it's me.

That line of code is unique to AutoEAC, so I'll have to let masterofimages answer it.

Hi Nitro
I think that sometimes it works and sometimes not. You must be right that it has to do with conversion of illegal characters causing thins to no match every time. I am now having the same problem as Cutestory. Is there any way to alert masterofimages to the new questions? Thanks again for clarifying the earlier issue.

I was getting this error, and I found it to be that you have the naming scheme set up wrong. Here is an example:

if you have EAC naming scheme set to be: %A\%C (%Y)\%N-%T

you should set your naming scheme in AutoEAC to: %A\%C (%Y)

leave off the actual filenames which for me is $N-%T . Try this, and if you need any questions answered let me know.

My EAC naming scheme:

%A\%C\%N-%T

My AutoEAC naming scheme:

%A\%C

Still getting the error. Also tried your specific example for naming scheme, and that doesn't work either.

Cutestory, try using AutoFLAC 1.1 and see what it does. If it works, then that likely means the problem is in the variable name code of AutoEAC, which masterofimages can look into next time he checks this thread. If AutoFLAC fails as well, however, then there's likely something else going on that affects both programs.

AutoFLAC works fine.

In fact, I was using it for a while when I noticed that AutoEAC had a couple of features I liked...being able to use my own naming scheme, as well as appending Accuraterip info to the logs. I guess I'll go back to using AutoFLAC, which itself is a wonderful program. I'll do without those features until masterofimages shows up again...

Thanks a lot everyone for the help!

Ditto here. This seems to be specific to AutoEAC. I too will go back to AutoFLAC until things are fixed. Thanks again to everyone for their help.

Ok, Nitro,
I have been using AutoFLAC for a while now, and I have discovered a problem. Sometimes on some albums, the cue sheet being created writes incorrectly. For example, it might write:

FILE "02-Goodbye.flac" WAVE
TRACK 02 AUDIO
TITLE "Goodbye"
PERFORMER "The Sundays"
INDEX 01 00:00:00
FILE "03-Life & Soul.flac" WAVE
TRACK 03 AUDIO
TITLE "Life & Soul"
PERFORMER "The Sundays"
INDEX 01 00:00:00
TRACK 04 AUDIO
TITLE "More"
PERFORMER "The Sundays"
INDEX 00 02:37:30
FILE "04-More.flac" WAVE
INDEX 01 00:00:00
TRACK 05 AUDIO
TITLE "On Earth"
PERFORMER "The Sundays"
INDEX 00 02:42:73
FILE "05-On Earth.flac" WAVE
INDEX 01 00:00:00
TRACK 06 AUDIO
TITLE "God Made Me"
PERFORMER "The Sundays"
INDEX 00 02:22:3

I have to go in and manually edit placing, for example,
" TRACK 04 AUDIO
TITLE "More"
PERFORMER "The Sundays"

beneath FILE "04-More.flac" WAVE

and deleting INDEX 00 02:37:30

Any ideas what is going on here?

If I don't fix it, Foobar will play the wrong song under the correct title.

Thanks!

nexus77,

It's not a problem of AutoFLAC, it's a ''feature'' of EAC ... a Noncompliant cuesheet

http://wiki.hydrogenaudio.org/index.php?title=EAC_CUE_Sheets
http://wiki.hydrogenaudio.org/index.php?title=Gap_settings

Most software doesn't support the noncompliant type, including foobar2k 0.9x

Actually, that's not an error. It's supposed to be that way, but the answer why is a little long.

EAC supports 4 methods for creating cue sheets. The one that AutoFLAC uses is labeled "Multiple WAV Files With Gaps (Noncompliant)". As indicated in the title, this can result in cue sheets that other programs may not be able to read. foobar2000 is one such program.

So, why did I choose this one? Because this is the only method that creates an accurate copy of the CD. The other options treat audio data in gaps differently - usually either discarding it or prepending it to the next song. The noncompliant option, however, properly maintains the gap data in both the audio files and cue sheet.

Since the primary purpose of AutoFLAC is to create a duplicate backup copy, I chose the noncompliant option to ensure that it yields perfect copies. I did test the other options, but found that restored CDs are different from the original, which defeated the whole purpose.

So, like I said, it's not really an error. It's annoying, certainly, but necessary.


Thanks, Cosmo. That's a much quicker way of saying what I was trying to get out.

Wow, this is truly an unending learning process! And to think that I have gone in and manually edited all of these cuesheets to playback properly. I guess all I have done is screwed them up! Nevertheless, this is good to understand. I am glad that this is working properly. I will not worry about it, then. I don't have to open cuesheets in Foobar anyway. I can just open the tracks themselves and direct Foobar to ignore cuesheets. I was just concerned that none of the discs would rip back properly from the cue sheets. Thanks for getting back so quickly. Hopefully this will be helpful to others as well.

Has masterofimages forsaken us?

First time poster. Love this forum, I've learned a lot! If this is a newbie question, please forgive my ignorance. I'm having problems using the write mode of autoflac. When it starts up, I load the cuesheet that was created when I ripped the cd. Then I get the following error:



Any help is greatly appreciated.

Daryl

...does the file exist?

If you're not sure where to look, let me know and I'll try to reply with a more detailed repsone later tonight.

Yeah, it (they) exist as flac's. But in the cue sheet above, they show up as wavs.

They're supposed to be .wav files. EAC doesn't natively support FLAC files. That's why I wrote AutoFLAC - to automate encoding to and burning from FLAC files.

When you run AutoFLAC in write mode and select a .cue file, it will parse through the cue sheet line by line and convert all FLAC files listed in the sheet to WAV files, then rewrite the cue sheet to reference the WAV files, which EAC can understand. All of these gets written to a temporary directory, which by default is a subdirectory of the album directory. The new cue sheet is then opened with EAC, which is processed to ensure everything is ready to be burned. You're obviously having a problem with that last step.

Do me a favor please. Run AutoFLAC in write mode again, select that CUE sheet, and let it run until it gets to the same error message that you posted before. At that point, just leave it sit there on the screen and do the following.

Run cmd.exe
Navigate to the directory where the FLACs and CUE sheet that you're trying burn are stored
Type in 'dir /s >c:\output.txt' and hit enter (without the quotes)
Paste the contents c:\output.txt to the forum

Also, please run regedit and let me know the value of these two keys:

HKEY_CURRENT_USER\Software\AutoFLAC\
[writetempdir]
[writetemptype]

This will help me troubleshoot your problem.

Here's the output.txt:

Volume in drive C has no label.
Volume Serial Number is 206E-1393

Directory of C:\Documents and Settings\Owner\My Documents\My Music\EAC Rips\Bootleg\Van Halen\Newcastle 5-21-78

09/05/2006 09:38 PM <DIR> .
09/05/2006 09:38 PM <DIR> ..
09/05/2006 03:09 PM 1,639 00-Newcastle 5-21-78.cue
09/05/2006 03:09 PM 3,449 00-Newcastle 5-21-78.log
09/05/2006 03:11 PM 7,734,254 01-vh1978-05-21-t01.flac
09/05/2006 03:11 PM 27,644,575 02-vh1978-05-21-t02.flac
09/05/2006 03:11 PM 6,925,434 03-vh1978-05-21-t03.flac
09/05/2006 03:11 PM 24,019,681 04-vh1978-05-21-t04.flac
09/05/2006 03:11 PM 21,452,973 05-vh1978-05-21-t05.flac
09/05/2006 03:11 PM 20,598,524 06-vh1978-05-21-t06.flac
09/05/2006 03:11 PM 22,215,336 07-vh1978-05-21-t07.flac
09/05/2006 03:11 PM 24,918,404 08-vh1978-05-21-t08.flac
09/05/2006 03:11 PM 20,280,867 09-vh1978-05-21-t09.flac
09/05/2006 03:11 PM 25,704,726 10-vh1978-05-21-t10.flac
09/05/2006 03:11 PM 36,125,685 11-vh1978-05-21-t11.flac
09/05/2006 09:38 PM <DIR> AutoFLAC
09/05/2006 03:14 PM 649 ffp.txt
09/05/2006 03:13 PM 573 info.txt
15 File(s) 237,626,769 bytes

Directory of C:\Documents and Settings\Owner\My Documents\My Music\EAC Rips\Bootleg\Van Halen\Newcastle 5-21-78\AutoFLAC

09/05/2006 09:38 PM <DIR> .
09/05/2006 09:38 PM <DIR> ..
09/05/2006 09:38 PM 1,628 00-Newcastle 5-21-78.wav.cue
1 File(s) 1,628 bytes

Total Files Listed:
16 File(s) 237,628,397 bytes
5 Dir(s) 46,702,862,336 bytes free



And the values from regedit:

writetempdir = c:\DOCUME~1\Owner\LOCALS~1\Temp
writetemptype = album

VHROXU2:
I just wanted to make sure that you are using autoflac to convert a cue sheet that was also created with autoflac. Autoflac will not read a cue sheet you created with EAC. Forgive me if this seems an obvious statement.

vhroxu2, based on the info posted, it looks like nexus77's assessment is correct. AutoFLAC's write mode currently requires that it be fed a CUE sheet that was originally created with AutoFLAC's rip mode. This is a limitation that I plan to fix in the next version, just haven't gotten to it yet.

To confirm, please open up your original cue file, "00-Newcastle 5-21-78.cue". Look for the first line that begins with FILE (probably line 7, based on your previous screenshot) and check the extension of the file. If it's .wav, then AutoFLAC will fail, for the reason listed above.

A workaround that you can try until I fix this issue would be to rename the file extensions in your original CUE sheet to .flac from .wav. AutoFLAC should (assuming no other differences) be able to work with it then.

The original cue sheet was created by autoflac. When I open it, the first FILE line is:

FILE "01-vh1978-05-21-t01.flac" WAVE

Again, when I open this cuesheet in autoflac write mode, I get the error in the screenshot above. I don't think autoflac is converting the flacs back to wav, thus telling me the file doesn't exist.

Totally confused.

Huh... I don't know what the problem is, then. I'll try to spend some time looking into it tomorrow night and see if I can figure out what the problem is.

Out of curiousity, does AutoFLAC work for other CDs you try to write, or do you always get this error?

Yes, it happens on all 5 that I've ripped.

vhroxu2, can you please post or PM me one of your .cue files?

Nitro, pm sent.

Well, I just tested this out on my own system, and it worked perfectly. I still don't know what the problem is, but I'm going to post a very detailed step-by-step account of what I did to get this to open of in EAC correctly for burning. Please repeat these steps and let me know where it fails.

First, copy your .cue file and tracks 01 and 02 to a separate directory for testing. You should have three files in this directory:



Note: The two FLACs I'm using for testing are simply copied and renamed from another album. Please use your originals.

Next, edit the test CUE sheet so that it looks exactly like this:


All you should need to do here is delete everything after line 16. The first 16 lines should already look like this - if they don't, then something's wrong.

Next, click Start, Programs, Exact Audio Copy, AutoFLAC (Write Mode). Navigate to and double-click on the test CUE sheet:



At this point AutoFLAC should begin converting the FLACs to WAVs. You'll see a progress window like this, and the progress bar will increase after each file is converted:



The CUE sheet and both FLACs will be converted and saved in a subdirectory of your test directory. This subdirectory will be named AutoFLAC, and will contain the converted CUE sheet and both WAV files:



If you open the converted CUE sheet, it should look exactly like the original, though the .flac extensions will be changed to .wav:


Finally, after the FLACs and CUE sheet have been converted, AutoFLAC will automatically load the CUE sheet into EAC. This is what a successful test will look like:



Please perform this test yourself exactly as I have described above and you should be able to figure out where the error is occuring.

Nitro - I did EXACTLY what you posted above. When it got to the point of converting the flacs, the "preparing files for writing" window disappeared very fast (was up for maybe 2 seconds, too quickly for actual conversion), then I get the same error as before (error in cue sheet, file does not exist in line 7).

Ok, try this. Run regedit, and let me know what this value is:

HKEY_CURRENT_USER\Software\AutoFLAC\
[flac]

Then, run cmd.exe and paste that value into the command prompt and hit enter. What does it do?

The value from regedit is - C:\Program Files\FLAC\flac.exe

When I put in the value in cmd.exe I get the following:

That looks right. Sigh.

I'm out of ideas at this point. Everything seems like it should be working fine. I don't know why your FLACs aren't being converted. The fact that I can't duplicate the problem on my system makes it especially difficult.

The next step would probably involve a special debugging build of AutoFLAC to print out some additional information of what's happening when. Stuff like echoing file names, directory paths, etc. However, I can't commit to working on that at this time. Maybe in the next week or two.

Alternatively, since AutoFLAC is open source, you could try doing a little trhoubleshooting yourself. Have you ever done any coding before? If so, download the AutoFLAC source code and binary archives and try playing around with it, see what you can find out. Your problem's likely occuring between lines 133-146 or 176-179 (I would guess the latter).

Otherwise, I'll look into this some more as time permits.

Wow, this program is exactly what I need to backup my CD collection. Thanks for your work, Nitro. Is there any way to support "Test and Copy" Mode in EAC? For my CDs, I usually make sure that Test CRCs match Read CRCs. This info is then written to the log file for verification purposes.

I am wondering if I am just being paraniod, or would a feature like this add anything?

Thanks again!

I'll check it out and see.

Thanks. The reason I ask is that many of my older cds are scratched, and the ones that are badly scratched will extract perfectly, yet have mismatching CRCs, despite listing "No errors Occured" within the log. This way, I know if the copy is exact when the CRCs match, or if they don't, I know that my CD is bad. If this doesn't make sense I will try to explain it more, since I am relatively new here.

I know this is showing my ignorance, but can you explain why this would matter? Eg, if you rip your CD and EAC that reports "no errors occured", doesn't that mean that it made a clean rip? If you listen to the song, do you here any audio distortions? Pops, clicks, etc.? If not, then it sounds like a clean rip to me. Why does the CRC value matter?

This is an open-ended question, so any experts can feel free to chime in here as well.

Well, I'm probably wrong on this one, but I'd be happy to state my claim and ask that it can be either verified or rebuked by the community. Disclaimer: I have limited knowledge on the subjects involved, but remember reading this somewhere, possibly at hydrogen audio.

Basically, the problem arises from the fact that EAC in secure mode is not guaranteed to produce a perfect rip. It almost always does, but there are cases where it will report accurate results when in fact the results are not perfect. Usually when this is the case, there will be no noticable difference between the original and the copy, so it only really matters if we are concerned with perfection with regards to data.

The CRCs that EAC produces gives an even higher level of confidence that the data was produced exactly, than to trust secure mode alone. Basically, EAC calculates the checksum of the data on the CD before it is ripped and that of the data from the ripped file. If these match, we know for sure that the CDs are bit perfect. If they don't, well, we can assume that secure mode screwed up.

In practice, this has only happened to me a handful of times, I'd say about 5 times out of 100 (so far).

Please tell me if I am way off base on this one. I could be making half of this up.
Also, how hard do you think this would be to implement? <-- edit, out of curiosity

I have no idea. I've been working on some other projects so I haven't had time to mess with AutoFLAC lately. I'll add it to my list of things to investigate once I start working on it again.

Right.



I don't know if "It almost always does" is correct or not.

And to clarify, EAC doesn't report "accuracy" (that's what Accuraterip is for), but rather, it reports that it did not *detect* any errors, which isn't the same thing.



Assuming your optical drive isn't defective and your EAC is configured correctly for it, I believe the above is the case.



As phrased above, that's not exactly true.

There are multiple kinds of damage that can generally be broken down into two categories: physical and intentional. Physical is the normal stuff: dirt, scratches, scratch/scuff damage to the read surface, gouge damage to the label size and rot/decay of the reflective layer, etc. Intentional damage is another kind where the bits on-disc have been modified to generate read and/or error-detection/correction errors, typically for copy-protection reasons.

The T&C CRCs that EAC produces give you a high level of confidence that certain kinds of damage are unlikely to be present, specifically ones that would tend to lead to different results on each rip. There are other kinds of damage that would tend to lead to repeated rips of the exact same incorrect data, however, and T&C doesn't help to address those.




Not exactly. Both are calculated from rips. The first checksum/CRC is calculate on a rip-to-memory where the rip data is discarded, the second is generated with a rip of the same track, but this time the track is saved to disk.



No, we simply know that each of the pair of rips gave us the same data, which isn't the same as knowing they are bit-perfect. It does, however, increase our confidence that certain kinds of damage were properly dealt with.



With AutoIT, it's probably possibly to screen-scrape the T&C values from the controls holding them. And it would be sort of nice to automate repeated rips of failing tracks, actually. You'd use T&C the first time to see if you get a match and if not, store the two values and continue ripping the track a la carte until you get a match with a previous value. Or automatically submitting those tracks to secure mode after some number of failed burst mode matches. Not guaranteed bit perfect, but certainly useful

Support for accuraterip would also be swell - that would have to pull match/no-match values from the rip report, where the accuraterip results are given.

-brendan

I find the program to work quite well. I especially like the Write Mode feature, since only EAC has support for both Write Offset AND non-complient cues. Goodbye, Burrrn.

I, too, would also like to see:
1. Support for test and copy [high priority]
2. The ability to modify the naming scheme. [lower priority]

In any case, I will ALWAYS use the Write Mode in the future. HUGE thumbs up.

Nitro 232, great, I was even thinking about looking at the code myself. Bhoar, thanks for clarifying my half truths.

Is masterofimages ever coming back to help with AutoEAC issues? (This is a rhetorical question; I'm just hoping he sees activity and decides to chime in.)

I'm still using AutoFLAC, and I tried to burn a CD today, and now I'm getting the same error as vhroxu2...and it's happening with every CUE sheet I've tried...

I checked the temp directory, and the WAVs are not being created, and they're not showing up elsewhere. The only thing in the AutoFLAC temp directory is a CUE sheet.

I'm gonna try not to start crying, since I've ripped about 300 CDs already.

vhroxu2, did you install or experiement with AutoEAC at all? Is it possible there's some odd interaction between the two causing the problems we're having? Is anyone else having problems writing CDs?

IIRC, AutoFLAC has a key sequence to force EAC to the AutoFLAC-compatible preferences.

Have you tried that?

-brendan

I'm not sure what you mean by that. Do you mean following the instructions in the README to setup EAC, or pressing a key combination (like Ctrl-C or something) within EAC or AutoEAC?

Sorry, I think I was getting the workings of AutoFLAC and REACT confused. The latter has a "reconfigure EAC to REACT compatible settings" option.

-brendan

Here's another suggestion (which actually was suggested by someone else for a completely separate issue, but may apply here as well). Check the following registry keys:


Is there a value named AutoRun in either of them? If so, try deleting it (or setting it to null) and running AutoFLAC again.

I'll try it when I get home! Thanks for the quick response!

EDIT:
That didn't work, but I installed EAX and AutoFLAC on another machine on my network, and that machine had no trouble with the same CUE files.

It's fixed, but I'm not sure why...

vhroxu2 and Cutestory, I'm working on a new version of AutoFLAC, and I've added a small bit of debugging code to try to figure out why the FLAC files are not being converted on your system. Please download this test version of AutoFLAC and use it to try writing a CD.

While converting the FLACs to WAV files, AutoFLAC will output the exact commands it's using to c:\autoflac_debug.txt. After AutoFLAC has finished converting all files, please open this file and paste the contents to this thread. This should help locate the problem.

Also, copy/paste one of those lines straight to the command line in cmd.exe and run it. It should work; if it fails, try to figure out why (path issue? cannot find flac.exe? etc.), as this will likely be the same reason AutoFLAC is failing. One note: you may need to create the "AutoFLAC\" output directory yourself, as AutoFLAC usually does this itself. If you get an error like this:


make sure that the output directory exists (in this case, C:\WINDOWS\TEMP\AutoFLAC\) and try again.

Please let me know what you find out.