Nitro - there's some sample code buried in the AutoIT forums to use the process ID of a process started by "Run()" (not Runwait) to query the return code of that process when it exists.

Let me see if I can dig it up...

http://www.autoitscript.com/forum/index.php?showtopic=23096

Not sure if that addresses some of the return code issues...

-brendan

Ahh, but that's the problem. I've used AutoIt to grab return codes in the past - easy enough. However, you must remember that AutoFLAC itself does not call flac.exe. EAC does. AutoFLAC only automates all of the stuff that happens before and after encoding.

Like I said, I started to play around with this for the last version (actually, I think for the last couple versions - verification of some kind has been a long-standing request), but I got stuck at this point. Since flac.exe doesn't seem to output success/fail messages for verification, I wasn't able to have AutoFLAC check and report on anything.

Basically, I think one of three things would need to happen to make this work:

1. Pass the -V switch via EAC and have it recognize/report on it. This would probably be the best overall, though I find it extremely unlikely given that flac isn't even a native format.

2. Rewrite AutoFLAC, or write an additional helper application, that would be called by EAC and then in turn calls flac.exe to encode. This would do nothing but relay encoding calls from EAC to flac.exe, but since I control this binary I could also have it log verification results. I'm not really a fan of this option, though, as it seems rather wasteful.

3. Have flac.exe actually output some message (via stdout or stderr) when verification fails, which could be redirected to a log file during the ripping process and read by AutoFLAC at the end. Of course, this would most likely involve changes to flac.exe, which means that: A) this feature would require a future release of flac.exe, and B) it would be entirely dependent on the FLAC author being willing to make the change. One idea for this is that perhaps a -VV (verbose verify) switch could be added, which could give me the output I would need without changing the current behavior of -V (for any other programs that use it).

Honestly, my preferred solution would be option 3. In addition to solving the problem for AutoFLAC, it may also be beneficial for others who are not quite sure how to utilize the -V switch.

Of course, all of this assumes that there isn't already some easy way for flac.exe to report this information. It also assumes that I'm not missing something obvious about having AutoFLAC read flac.exe return codes when run via EAC. If either of those cases are true, please, by all means, set me straight.

This allready works EAC has an option which will show a warning dialog whenever an external command-line encoder returns a non-zero return code : EAC > Compression Options > External Compression > "Check for external programs return code".

It allready does

Well, I suppose you could periodically walk the process tree (there's code out there for that too) and note all children of EAC that have an image name of flac.exe, then register and monitor them to find their results

Alternately, just looking at all flac.exe processes in the process list in some circumstances might work. A bit klunky, but that's the category of the things that AutoIT is good at.

The above gets more complicated if you're doing track rips, of course, since you'd have to grab the entire command line and parse that, ugh.

Assuming that flac.exe return codes are being reported correctly on exit.

Perhaps the previous post's suggestion is the key?

knowing that while it's easy to come up with good ideas, good solutions are often difficult,
-brendan

flac.exe will print a unique message if verify fails, which looks like:


(%s is the input or output filename) it goes to stderr like all the other output. can you parse that? the last 'Verify FAILED! Do not trust..." line is unique enough and will only show on a verify error.

Josh

Thanks for the corrections. Either one of these solutions should work. I'll just need to spend a bit of time playing with and testing each of them.

Is there any way that I can force a verify process to fail? I need to test both success and fail cases, and I've had a test case fail (which is probably why I was unaware of this message).

I hope not! not without recompiling anyway. the easiest way would be to force verify_error to be false in src/flac/encode.c:EncoderSession_finish_ok()

Josh

What about somehow corrupting a .wav file before trying to encode? Or maybe deleting the .wav while it's being encoded? Or anything that may cause flac to choke?

If this was under Linux I'd try out your recompile suggestion, but compiling anything under Windows is just not worth the effort. There has to be some way to cause this to fail, though. What are the conditions that flac looks at in order to determine whether or not something has been successfully encoded? Is this documented anywhere?

for verify to fail, encoding has to generate a flac file that does not decode to the original. if you can do that with any input, that would be a bug in flac. it has never happened yet. it's not enough to corrupt the input. if you corrupt it so it's invalid WAV, flac will reject it with an error even without -V. if you corrupt some audio samples but the WAV is still valid, flac has no way of knowing the audio is corrupt and even it if it did, that would not be a verify error.

Josh

Damn, that was a fast reply.

So if what you say is true, then, it seems like the likelihood of flac.exe failing is this regard extremely low. I have to wonder, then - is this even worth the effort? I can't even begin to imagine how many flac files you must've created in your own testing and usage. If it has never happened to you, what's the likelihood that it may fail when encoding freshly ripped tracks?

Basically it sounds like I have some people on the one hand asking to verify the integrity of their FLAC collection (which I can understand), and on the other hand I'm being told that the encoder is robust enough such that it just won't fail.

I'm just thinking out loud here. Feel free to respond with some more comments. I'm not trying to wiggle out of this, just want to get a better understanding of what benefit it would provide. I have this nasty habit of really wanting to understand whatever I'm working on. Terribly inconvenient sometimes.

Before Josh releases a FLAC release to the public, then it has to first pass the FLAC test suite on several different platforms and the FLAC test suite checks every little tidbits in the FLAC release and the test involves processing several thousands of streams in a encode-decode and verify process and takes several ours. So, IMHO, then the likelyhood of getting a verify error with flac.exe is of the same likelyhood as of a hardware failure occuring. Personally, then i don't use -V, as i have full confidence in Josh's work and his testings, but i'm not saying that it's useless either, since it is indeed a very nice option for making sure that you won't get a bad encoded file because of a hardware failure occuring. If i where you, then i would just tell people that use your program that if they use flac.exe's -V switch, then they need to enable the EAC option that checks for returned non-zero return codes and which shows a warning dialog with the name of the file that failed in this situationon

EAC > Compression Options > External Compression > "Check for external programs return code".

The -V was brought up due to nexus77 thinking his flac was not encoding losslessly, right? Then Imimmo almost immediately brought up his complaint of the wait for flac to finish before the next CD is requested.

Hmm, I may have gotten confused when nitro made a post that addressed *both* the -V option as well as the "wait for flac to complete" issue. It seems that, at this point, everyone agrees that the chances of flac.exe failing, other than due to hardware or disk space issues (the latter autoflac could monitor), is low enough that the result of the encoding process doesn't really need to be monitored, yes?

If so, then allowing the encode to be asynchronous is less of a problem, allowing nitro to make it configurable...and that may also help him to trace the cause of the kinks some people had with the original approach.

-brendan

martin brings up an interesting point... people who overclock too much or have bad ram or some other hardware problem can get verify errors, and lots of times they don't even know it, so I guess it is still a good thing to check.

anyway, I can pm you a hacked up binary that will always fail verify if you decide to implement the checking, lemme know.

Josh

I am getting this AutoIT error with AutoFLAC 1.2 using FLAC 1.1.3b and EAC:

------------------------------------------------------
Line 0: (File "C:\Program Files\Exact Audio Copy\AutoFLAC.exe");

$pid = run("" & metaflac & '" --add-replay-gain ' & $list, $ripdir, @SW_HIDE)

Error: Unable to execute external program.

The directory name is invalid.
-------------------------------------------------------

This happens whenever I try to rip a track and enable ReplayGain. The actual encoding of the FLAC file works just fine. I'm not sure which directory name was invalid. I made sure that metaflac was where I said it was. I also copied metaflac to the same directory as AutoFLAC. Nothing seems to work.

Any help would be appreciated.

This sounds like it's related to the custom naming scheme. Try setting it back to the defaults (I think that's listed in the readme file - been a little while since I've looked at it) and see if it'll work properly. If so, click the ? button to the right of the custom naming scheme fields and make sure that you follow the instructions in there. From previous feedback I've received it isn't too clear, so you may need to play around with it a little bit to get it right.

Chalk one up to user error. After going back to check the naming scheme, I realized that they did not match between EAC and AutoFLAC. I didn't even think to look at this because the FLAC encoding was successful. I didn't realize that EAC calls flac and AutoFLAC calls metaflac. Thanks for the help.

Not sure if this has been brought up yet (or maybe I'm doing something wrong), but I started encoding one of my CD's (full album) using Autoflac 1.2 and the files ended up with the .flac extension, but the lines inside the CUE sheet ended with the .wav extension, so when I tried to play the CUE sheet file in foobar2000, it wouldn't work. After changing the extensions inside the CUE sheet file to .flac, the audio files matched up correctly. What am I missing? (By the way, great program!! Takes the load and time off ripping CD's)

AutoFLAC should automatically convert the file extension in the CUE sheet to .flac. If that's not happening, then I suspect something must be failing in the process for you. I'd suggest checking the variable naming scheme options following the same advice I gave to the previous poster. That seems to be the most common problem.

Hi all,
i've been using AutoFlac for some time but had to move to a new computer.
Now i have some problems i do not understand.
1/ AutoFlac is ripping all right and creating a cue-sheet BUT after compression is finished the cue sheet is DELETED !!!
2/ The Multidisc (1 of 2 and 2 of 2) is not working any more, autoflac doesn't care about it
3/ autoflac does not copy the data files of a cd anymore.

As i said, ive done it before but now i do not get any errors just the compressed files.

Is there a way to debug what autoflac is doing to find the error?

The paths are alright, the files are stored and compressed.

In hope of help

difool

I've looked at it several times, but I'll go over it again to see if I missed something. Thanks!

I've found my error, reading helps a LOT

NOTE: This MUST match EAC's naming scheme, minus the filename portion.

So if i paste and copy the strings from EAC to AutoFlac i WILL have a Problem.

Greetings
difool

Yeah, I know. As I've said in previous posts, this seems to be a a constant "gotcha" for people, and I'll figure out a better way of handling this in the next version.

Glad you figured it out.

A note saying: "IF YOU ARE PASTING INTO THE ABOVE DIALOG BOX DIRECTLY FROM EAC, YOU ARE DOING IT WRONG" would be such a GUI eye-sore?

-brendan

I got caught by the same 'gotcha' and left a solution in a forum post a couple of pages back. This was right after the release of 1.2.

That "?" button next to the naming scheme dialog box is there for a reason, and I missed it too. Maybe replace the "?" with "Naming Scheme Help" or maybe open a new window to actually enter the two naming schemes at the same time, with an explanation inside the box itself.

In the new version of dBpoweramp, the secure ripper. it's much more complicated to set up the naming scheme. However, there is a 'preview' area that you can see what the result is.

Bug Report:

If there is a colon in the Album Title, AutoFLAC will copy an empty cue file into the rip folder, and will not copy the log file. Both files are left in the default rip [parent] folder.

Note that this cue file [the one that remains in the parent folder] has a path statement in front of all the file names and cannot be used to burn with directly. It will also call out the files with a WAV extension. Edit out the path and place new file in the ripped folder.

Or just solve the problem and remove the colon before you rip the disc.

First of all, thanks to nitro for autoflac. Seems to be just what i need.
I do, however, have a problem and need a little help please.

When i try and rip a 'various' cd, the cue file is not written.

My filename options are:

EAC naming scheme:
%D - %C (%Y)\%N - %T

EAC various artists naming scheme:
%C (%Y)\%N - %A - %T

Autoflac name scheme:
%D - %C (%Y)

I have just taken a look at the 'various' rips and the some have a '/' in the freedb listing. If that is the cause, how do i overcome it?
edit: also happens when i change the '/' to '-' in the freedb listing in EAC.

Any ideas?

Do you have any special characters in the CD Title or Artist name fields that are considered invalid for Windows file names? eg, a colon (, slash (/), etc.? That seems to be the leading cause of this problem.

Also, check in the root of the output base directory. Do you see the .cue file there? Or is no .cue file being written at all?

Thanks for the reply.
The cue file was being written in the output base directory but then disappeared. Not all of the 'various' cds had slashes but may have had some other invalid character. Rather than changing each track manually I am now unchecking 'various' option in EAC and it's working well enough for me now.

I do however have a problem when i check replaygain in autoflac. After the cd is ripped, an error occurs (can't remember the exact message but it's along the lines of a metaflac and replaygain error.
Hope you can help with this also. If you need more info that this, i shall recreate the problem and provide full error message.


sn

@ screaming ninja

In your naming schemes, replace %D with %A in both places [EAC and AutoFLAC naming schemes], then change your EAC various artists naming scheme to "Various Artists - %C (%Y)"

I had a problem similar to yours and this fixed it.

Here's my naming schemes:
EAC Naming Scheme : %A - %C (%Y)\%N - %T
AutoFLAC Naming Scheme : %A - %C (%Y)
EAC Various Artist Naming Scheme : Various Artists - %C (%Y)\%N - %A - %T

Also, you need the forward slash in the EAC/FreeDB listing or else the files get double named for Various Artist conversions. When it doesn't have it that way, change it in EAC like this: Database > Transform > Transform


I had to test to see what it actually did in my instance by setting it back to the incorrect settings. In my case, the cue was 1st written to the default [parent] folder, but got deleted in the move.

Another thing, canceling out of the pre-track gap detection will cause the cue not to be written.

Many many thanks RolloTomasi!!

Looks like you like to store your flacs in a similar way.

I've made the adjustments you suggested and the cds are ripping well now. Luckily i was only 20 cds into my collection!

Thanks to you and nitro all for your help. It is much appreciated.


sn

I've been trying to use AutoFlac but I'm running into a quirk.

I run the script, everything seems fine, the CD is ripped, the compression finishes .. and then nada.. no CD eject, no notify, and the script stays as paused. To rip a new CD I exit the autoflac.exe and then re-launch it.

I run Windows XP SP2.

Thought I'd ask for help as I have no idea what to do. Same thing happens if I use image or individual files, with and without a .cue sheet.

Cheers

BT

I suspect there is an error in the naming scheme. The naming scheme in EAC and AutoFLAC must match, except that the AutoFLAC naming does not include the file name portion. See my post to screaming ninja above.

Is there any way to control the naming scheme of the LOG and CUE files?
By default they come out as: 00-<album>.cue/log
Just how you set it as default, I like them to match how I have my tracks named which is artist - album - track - title
I would like to have them in this scheme: artist - album - 00 - EAC
(various would be: album - 00 - EAC)
So in the folder it would look like this:
2 Bad Mice - Kaotic Chemistry (SM-8013-2) - 00 - EAC.cue
2 Bad Mice - Kaotic Chemistry (SM-8013-2) - 00 - EAC.log
2 Bad Mice - Kaotic Chemistry (SM-8013-2) - 00 - Playlist.m3u
2 Bad Mice - Kaotic Chemistry (SM-8013-2) - 01 - 2 Bad Mice.flac
2 Bad Mice - Kaotic Chemistry (SM-8013-2) - 02 - Drum Trip.flac
etc....

I currently do this manually but if it's automated, that would be awesome.

Plus add support to change the EAC generated m3u file name

Pretty sure there is no way to change this in EAC, it uses its own setting, <album title>.cue or .log. AutoFlac looks for this layout then changes the file name by inserting 00- preceding, then moves it to the rip folder, removing the path statement from the cue file in the process. So to answer your question, no, unless you can hack the code somehow.

An option to run minimized would be nice.

Me again,
has someone tried the multidisc option? I know it used to work but i can't find the error.
Here is what's NOT happening:
1/ The files are not renamed correctly; there are supposed to be renamed with the leading number of the multidisc (1 for the first disc, so 101 presents track 01 of disc 1)
2/ the Cue-sheet is not updated according to these filenames, in fact even the directory name is kept.

Otherwise it's working fine.
Greetings
difool

Hi,
A comment and then a question. I have been using EAC for years (ripping and converting) and have it down pat I reckon. (Mostly).
I just started using AutoFLAC and love it. So simple. I have noticed those weird naming problems coupled with incorectly named cues and logs etc. It seemed to happen at first with no rhyme or reason but I seem to have got it sussed by making sure there are no \ or / or - or any other unusual characters other than ( or ) in the titles as they translate as actions or have other meanings. CDDB seems to have some mixed up CD lists so I always make sure it is correct. Also on compilations I always make sure I use the option in EAC --> DATABASE-->Transform actual cd information-->transform '-' to '/' [Artist/Title] then make sure the artist is first and the title is second in the main window. I also dont use the multi disc option much now as this just seems to complicate it more. (This may just be due to user error on my part). I just put (disc 1) etc in the title and get seperate folders as output.
If you get a problem with names etc. once you are done then you invariably will have a prob with the cue sheet also.
I also have the directorys path in EAC with a following "\" ie D:\Albums\ , but in AutoFLAC without, ie D:\Albums . Not sure if this is a biggy.
Anyway I dont seem to get any probs now but if I do its always something to do with the CD details in the EAC window.
[EDIT] My naming scheme :- EAC --> %A\%C\%N-%T or Various Artists\%C\%N-%A - %T
AutoFLAC %A\%C\ [EDIT]

Now my questions. When burning with EAC from an image or files created with a different drive (I have 3) what do I set my write offset to? Do I leave it as tested or do I add/subtract the read offset of the drive that created the files/images?

On one of my machines I get the error " ERROR: EAC could not be started". I have to start EAC first then AutoFLAC and everything is fine. I cant however right click on a cuefile and launch writemode and by using the AutoFLAC write mode shortcut it starts the writemode going, decompresses then quits without launching EAC and deletes the decompressed files. My other machine works fine. Both are P4 Hyperthreaders with 2GB ram and XP SP2. Both use external ASPI interfaces in EAC and both have other burning apps installed.

Sorry if I ramble, great prog mate and cheers for any help in advance

Oz

Hi,

Thanks for creating this tool! I'm just getting back into ripping and it looks like it'll be very helpful.

What I want to do is create a FLAC Image+Cue Sheet as well as MP3 tracks for each rip.

Those of you using this tool to create CUE sheets and FLAC images...
...how are you going about creating MP3 tracks? (assuming you are creating MP3s of course

Thanks!

Well, since its called AutoFLAC, I don't suppose its the number one usage for the program.

You can use the AutoFLAC program for the flac image/cue, then, use a different program or EAC itself for the mp3 conversion [which would likely involve a re-rip].

hrmmm...maybe I should start a new thread? Or maybe do more research?

What I'm looking to avoid at all costs is reripping after taking the time to make my high-quality FLAC image and cue sheet of a CD. I'd like to create properly tagged MP3's of all the tracks from the image.

I suspect many others are doing this as the FLAC images and cue sheets would be for digital archiving purposes while the MP3's would be for everyday listening.

Thanks!

Ripping to flac image with cuesheet and to separate mp3's in one session I do with the help of MAREO. Maybe you can search for info here at the forums about it. The flac image I use for everyday listening by cuesheet and for archiving. The mp3's are for my wife's discman.

What settings do you use for the cue/flac creation? I have been using MAREO, but for some reason, I thought I couldn't do cue/flac.

I have been using AutoFLAC for awhile now and love it.
I just did a fresh install of windows and now I get the following error above.
It rips all the tracks and what not but fails to do the replay gain and the cue.
I'm sure it's something stupid I'm overlooking.
Any suggestions?

I can think of two possible issues that may cause that error:

1) make sure the math for metaflac.exe is properly set
2) check to see if you're using any special characters in the artist or album name (colon, question mark, etc.). If so, try removing the special characters and rip again to see what happens.

Well, it's not number 2.
What do you mean by "math" in number 1?

err, "path". Sorry. Make sure that the path is properly set. Eg, copy the path to metaflac.exe that's shown in the AuthFLAC GUI and paste it into cmd.exe. Does it run, or does it say something along the lines of "command not found"?

I figured it out.
I copy/pasted what I had for naming from EAC to AutoFLAC and forgot to remove the track and title.

Is there any way to change the naming scheme for log and cue?
By default it is: 00-cdtitle.log/cue
I would like to make it: 00 - cdtitle.log/cue

Right-Click > Rename

There's no automatic way to do it at this time. Variable naming was a new feature in version 1.2, and it still has a few rough edges in need of polish. I've been planning on putting out a new version to clean up many of the commonly reported issues, but I just haven't had time to work on it. I haven't forgotten about it, though. I still have a couple other issues that are taking precedence right now, but it hopefully won't be much longer before AutFLAC rises back up to the top of my todo list.

Some help please, I'm having the following problems ripping CDs using AutoFLAC.

1. The img, cue, and log files are not being placed into their own directory, rather they're being dropped all in the base directory.

2. The log and cue files have (AutoFLAC) entered into their file names just before the .flac. I have to delete this so that the file names match up with the file name in the CUE sheet.

3. After the "FILE" entry in the cue sheet the file name is correct, but after the file name instead of FLAC it has WAVE.

Here are my naming conventions:

AutoFLAC Name scheme: %A - %C
AutoFLAC Image scheme: %A - %C
EAC Naming scheme: %A - %C\%N - %T

Any ideas? Thanks for the help.