Updated: 10/16/2006
Version 1.2 Released - This release includes support for variable naming schemes, much improved write-mode capabilities (including a new options GUI), ability to write from CUE sheets created with other applications, and a few important bug fixes (among other things). Complete details below.

I just finished writing a new "frontend" (more of an automation script, really) that automates backing up and restoring CDs using EAC and FLAC. I know there are at least a couple of similar applications out there (flacattack and REACT are the two that I'm aware of); however, despite being great apps themselves, neither supported all of the features that I was looking for. So, I over the last week or so I wrote my own script, and I'm posting it here as I feel that some others may be able to benefit from it as well.

At this point I'm sure you're wondering, "What's so special about this script?" The three main features, and primary reasons I wrote the script, are:

• FLAC write support - The single greatest feature of EAC for me is it's ability to generate CUE sheets from an audio CD and reuse these CUE sheets to create a perfect duplicate of the CD of the original is ever lost, stolen, or damaged (anyone that has had CDs stolen will understand why this is important). However, EAC only supports WAVE files when writing a CD, which means previously compressed tracks must first be converted to WAVE files. AutoFLAC automates this process by decompressing all tracks, converting the CUE sheet to reference WAVE files rather than FLACs, and loading the CUE sheet in EAC's cd-writing interface. After writing is complete, AutoFLAC will remove all temporary files.
• Multi-disc support - This is probably more of a personal preference than anything else, but I really wanted an app to automate this for me. Rather than ripping discs that are part of a single set to separate album directories, AutoFLAC can automatically renumber and retag discs so that they are saved to the same album directory. If enabled in the AutoFLAC GUI, the disc track numbers will be renumbered Nxx, where N is the disc number and xx is the track number. So, track three on disc two of a two-disc set will be numbered as track 203.
• Data file support - AutoFLAC can check for the presence of a "data" track on an audio CD, which typically contain bonus material that can be viewed on a computer. If enabled, AutoFLAC will copy all deta files to a Data subdirectory of the album after the ripping process is complete.

Full details and download links can be found on the AutoFLAC home page. I always enjoy feedback, so if you download it and try it out (or just have any questions), let me know!

Direct downloads:

Installation Package - http://www.c1pher.com/autoflac12.exe
Binary Archive - http://www.c1pher.com/autoflac12_noinst.rar
UniExtract Source Code - http://www.c1pher.com/autoflac12_source.rar

Installation Package
Binary Archive
UniExtract Source Code

Changes in version 1.2

Thanks, and I hope you find this as useful as I have.

Just downloading the app for testing. Just wanted to inform you that the screenshots do not display in Opera. They display fine in IE and Firefox.

audiomars

That's odd. I'll look into this tonight and see if I can figure out what's wrong.

Thanks for letting me know.

Ok, I fixed it, though technically this was more Opera's fault than mine. :-) I use alpha-channel transparency in my images, which IE does not properly support. In order to fix this I run a script that checks for IE running on win32, and if found it does some magic that fixes the transparency issue (I found the script online, so I'm not clear on the details).

Anyway, after playing around with Opera for a little while I realized that it was identifying itself as Internet Explorer. Bad Opera! Since it already supported the images correctly, the javascript hack was essentially hiding the images for some reason. So, I figured out a way to make my script also differentiate between real IE and fake Opera IE user agent strings. This should solve the problem, though the proper solution would be for Opera to identify itself correctly.

Anyway, thanks again for the heads up. Everything should be working correctly now.

FYI, I just posted v1.0.1 to my site. It's mainly just a bugfix release for a few issues I found during additional testing.

This is great! Thanks, nitro.

A constructive criticism, if you don't mind?

My own preference would be for full-disc FLAC image + cue, instead of multiple tracks plus cue. Why? The hidden track (Track 01 Index 00) issue, and secondarily the loss of metadata (e.g. TOC, etc.). Without the full-disc image, the hidden tracks are stripped away, making AutoFLAC substantially less trustworthy for archiving CDs.

-brendan

This looks really promising. I'll try it later. The hidden-track issue is really important for full disc backups.
Question: Is there any checksum created? I use to verify my backups before restoring/re-burning them.

I haven't tested it out yet, but do you plan on supporting more lossess codecs? I'd be seriously interested if it supported WavPack as my entire collection is in that format.

Hi nitro, sorry for making you hack through code when it was Opera's fault . Now the site loads properly in Opera. I tried it out and I find it very useful. However, as brendan suggested, maybe there could be an option to use a single full-length flac or use split flac files. That and support foe WavPack would make it just about perfect

audiomars

I'm always up for some constructive criticism, so don't be shy.

I explained on the AutoFLAC web page why I chose to use individual FLACs rather than a separate image. My opinion on that subject still stands, for the reasons given. However, the hidden track issue that several people have mentioned is new to me. Can someone please explain that more thoroughly, or point me to a good reference? I'm assuming that you're not simply referring to the"bonus" track that many CDs include at the end, right?

bhoar, you mentioned something about a metadata issue. Could you expand on that as well? What information would you get by creating a single disc image vs. separate tracks? Currently AutoFLAC will tag each track with Artist, Album, Genre, Year, Title, and Number. The .cue sheet saves most of this information as well as CD-TEXT, including the DISCID. What's missing?

elmar3rd, no checksum is currently stored. Honestly, this has never occured to me. How do you create the checksum, and how do you verify it? I'll certainly consider this for the next release.

ChangFest and audiomars, while I don't have anything against WavPack, the name of the program is AutoFLAC. There's a reason for this. I chose to use FLAC as my storage medium because it's extremely well-supported across all platforms, and given that I generally use Linux, this is very important to me. I'll look into the possibility of supporting other formats, though.

One thing to keep in mind is that I originally wrote this to fulfill my own requirements. I posted it here, as I said in my first post, because I think it's a very useful program and I felt it could help others as well. I honestly would be more than happy to add support for additional features if it will be used by other people, but I didn't want to waste a lot of time up front coding features that I won't use if no one else was using it either.

Since it looks like there are at least a few people interested in using it, though, I'll be happy to look into extending it. I'll post an update once I've had a chance to test out some ideas. In the meantime, I'd really appreciate it if you could answer my questions above. Thanks.

I use to add MD5-checksums to all I back up on CD-R/DVD-R. This is an easy way to verify it later. There are a lot of MD5-Tools.
This could be a nice feature for AutoFLAC. But as you already mentioned, it is not that important to waste precious time for it.

Ok, I won't be shy!

And nope, it's not the bonus track at the end of another track. It's a bonus track found *before* the first track. A technical explanation of the hidden track issue is this: some CDs have an additional song stored in at the Track 01 Index 00 mark. However, most CD rippers start ripping at Track 01 Index 01 when in track-extraction mode, losing the audio between index 00 and index 01.

CD Players also start playing at Index 01, so in order to hear the song on a CD player, you have to rewind "back into" index 00.

The daefeatures site catalogs drive features, including the "Hidden Track One Audio" feature:
http://www.daefeatures.co.uk/htoa.php

You can see in the example CUE file accompanying the test image how it works.

Regarding the metadata, I am a bit more fuzzy on that: I'd just seen it discussed in the forums as one reason to create a single FLAC for the disc. Basically, I'd want to make sure that if I burned a copy of my FLAC-archived disc that freedb lookups would stillwork on the CD-R (important) and any normal special tracks would also be part of the archive (less important).

-brendan

PS - I'm planning to use AutoFLAC, myself, for archiving my own (and some other folks') collection using a robot. I have already written a CLI tool to control the robot and an external (independent) script to use the tool to tell the robot to unload a finished disc and load a new disc every time a disc ejection is detected. I may make some changes to the AutoFLAC script once I start using it, and I'll be sure to feed them back to you when I do so.

[quote name='elmar3rd' date='Jun 15 2006, 14:21' post='403288']I use to add MD5-checksums to all I back up on CD-R/DVD-R. This is an easy way to verify it later. There are a lot of MD5-Tools.[/quote]

So you run md5 on the .flac file after it's already been extracted and converted? In that case it sounds like you're only verifying the integrity of the .flac file itself (if, for example, you copy your collection from one drive to another) rather than somehow verifying it based on the original CD track. Is this correct?

Just trying to get a better understanding.

[quote name='bhoar' date='Jun 15 2006, 15:29' post='403305']And nope, it's not the bonus track at the end of another track. It's a bonus track found *before* the first track. A technical explanation of the hidden track issue is this: some CDs have an additional song stored in at the Track 01 Index 00 mark. However, most CD rippers start ripping at Track 01 Index 01 when in track-extraction mode, losing the audio between index 00 and index 01.[/quote]

Ok, I get the concept, but not sure I understand why the current method fails. Whether I use EAC to rip tracks to a single WAVE file (image) or individual WAVE files, would it not start reading at the beginning of the audio information? Is it a confirmed issue that EAC disregards any leading information when ripping to individual tracks? It seems odd that it'd read the disc differently based on how the data is output.

[quote name='bhoar' date='Jun 15 2006, 15:29' post='403305']Regarding the metadata, I am a bit more fuzzy on that: I'd just seen it discussed in the forums as one reason to create a single FLAC for the disc. Basically, I'd want to make sure that if I burned a copy of my FLAC-archived disc that freedb lookups would stillwork on the CD-R (important) and any normal special tracks would also be part of the archive (less important).[/quote]

I've tested CDDB (actually, freedb) lookups using CDs restored by AutoFLAC, and it was recognized correctly. Like I said, the individual flacs and associated cue sheet should contain all meta information that the flac images contain. If anyone can proove me wrong, though, feed free. [/quote]

[quote name='bhoar' date='Jun 15 2006, 15:29' post='403305']PS - I'm planning to use AutoFLAC, myself, for archiving my own (and some other folks') collection using a robot. I have already written a CLI tool to control the robot and an external (independent) script to use the tool to tell the robot to unload a finished disc and load a new disc every time a disc ejection is detected. I may make some changes to the AutoFLAC script once I start using it, and I'll be sure to feed them back to you when I do so.[/quote]

Sounds interesting. You're using an actual, physical robot to swap out the discs? Sweet!


Edit: Hmm... does anyone know why my quotes aren't displaying properly in this post?

I believe that is the case, yes.

When in track output mode, EAC allows you to configure your preferences to save the Index-00->Index-01 audio, typically called the "gap"m either at the end of the previous track or at the beginning of the next track.

1. Putting the gap onto the next track produces some pretty annoying side effects in general.

2. Putting the gap onto the previous track doesn't help with HTOA because there is no Track 00.

See:

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

-brendan

The Red Book defines the pre-gap of track one to be between 2 and 3 seconds long(the time from INDEX 00 and INDEX 01 of track one), so the CDs that have hidden tracks in the pre-gap of track one isn't compatible with the CD-DA spec(Red Book). The INDEX 01 of track one identifies the start of the first track, and as bhoar previously said, then this is where the CD players begins playing from and EAC begins ripping from in track mode(without changing the gap treatment settings away from the default setting).

The discs burned from separate tracks with cuesheets will also be capable of doing freedb lookups even if the original CD had a hidden track in the pre-gap of track one. This is because EAC adds a PREGAP statement at the beginning of the first track in the cuesheet so that the writer during writing will generate a pre-gap with null samples of the same length as the hidden track, so that the discid will be computed identically on the copy as to the original, but just will have silence in the pre-gap instead of the hidden track.

There are no differences in the metadata from separate tracks with cuesheets compared to images with cuesheets.

Yes, exactly.

elmar3rd, I've implemented MD5 verification in the development version of AutoFLAC, but based on my initial testing so far it doesn't seem very useful. For example, simply changing the track's comment tags (whether fixing an error in the track title, or adding a new tag such as PERFORMER) yeilds a different MD5. Therefore, if you make ANY updates or changes to the .flac file after it's initially ripped and tagged, it'll fail verification.

Like I said, this doesn't seem very useful. Perhaps there's a better way of implementing such verification that's a little more robust and can handle tag updates. Any ideas?

bhoar and Martin H, thanks for the excellent explanations of HTOA. I did some testing using the files at the link provided, but it turns out that my drive is apparently incapable of ripping audio from track 01 index 00. It seems to recognize that there is indeed audio there, as I get the appropriate amount of leading data, but it's just silence. After doing some additional searching through the forums it seems that if I get silence on the test CD then I'm pretty much SOL. Sigh, figures.

To everyone else, I'm currently looking into supporting both flac images and WavePack. These will both take some time to implement, though, so please be patient.

Ouch. I've got on the order of 25 CD/DVD(-ROM,-R,-RW,+R,+RW,-RAM) drives here I need to compile a DAE features list with in the next couple of weeks. If you can't fine one nearby to test on that does HTOA, I'll try to send one your way. No promises other tasks are taking priority: just stopped myself halfway done setting up a test station for this, and decided I'd better stick with my current (growing) TODO list. But it's there, item 17 at this point.

-brendan

If the FLACs are encoded with the -V switch, then there isn't any reason for verification IMHO, but to test the integrity of the file without concern for tag updates etc, then you can use the -t switch of flac.exe.

"flac will exit with an exit code of 1 (and print a message, even in silent mode) if there were any errors during decoding, including when the MD5 checksum does not match the decoded output. Otherwise the exit code will be 0"

Wow, I never realized that flac files embed an MD5 signature in the file by default. This seems like it should do the trick.

However, I'm not exactly sure how this is supposed to work. For example, look at the following output:



The stored MD5 hash does not the md5sum of the decoded WAVE file. How is the stored hash generated, and how exactly can it be used for verification?

Or here's another idea: EAC calculates and stores the track's CRC value in the log file. Can I use this for verification?

Unfortunately, I can't figure out how this is supposed to match up to anything. Even if I decode the flac and then open it in EAC's WAVE editer, it gives me a different CRC than is in the log.

Hi nitro322

During encoding, then flac.exe calculates a md5 signature of the raw audio data(without the WAV header) which then gets stored in the FLAC file. When decoding the FLAC file back to WAV format, then flac.exe checks for errors in the stream while also checking that the stored MD5 signature matches with the decoded raw output data. The -t switch of flac.exe does exactly the same as when using the -d switch to decode to WAV, but the only difference is that no output file is written.

EAC also calculates it's CRC values on the raw audio data without the WAV header.

Thank you. I'll be patient

I'm working on adding support for flac images, but I have a few questions about how exactly it should be done. Since I don't use this method myself, I'd appreciate some input from a more knowledgeable person so that I make sure I implement it correctly.

Output location
How are flac images normally saved? Normally I use the following structure for individual tracks:
$output\$genre\$artist\$album\
Should I do the same for the flac images? Or since since each filename should be distinct, would it make more sense to just save everything directly to $output\?

File names
By default EAC names the images "Artist - Album.ext". Should I stick with that format, or is there a better naming convention I should follow?

Embedding cue sheets
I see that I can embed the cue sheet using either flac (during initial encoding) or metflac. Is there any particular advantage to using one over the other? Is EAC able to natively embed the cue sheet, or should I always rip to an uncompressed wave and the encode and embed the cue sheet myself?

ReplayGain
How do I apply ReplayGain to FLAC images? Does it automatically know how to split up the tracks, or do I have to instruct it somehow?

I think that should cover it. I'd really appreciate any feedback you could provide. Thanks.

Re: Output location and filename, I am of multiple minds on this but the central idea is that these will be long term archives, so...
a) make the path and filename user modifiable
or
b) if not or if you just stick to $output/, make sure the filename is unique, just in case you have two editions of the same CD (e.g. a UK vs. US pressing and/or a rerelease) that differ slightly. For flac, I'd be OK with "Artist - Album (freedbid).ext".

The other items, I will leave to people more versed in the arts.

-brendan

@nitro322

Output location:
EAC asks for the location to store images. It would be *nice* to have it create directories based on tag variables.

File names:
The default of "Artist - Album.ext" is cool, but if you could allow one to use something additional, like "Year", that'd be cool. FYI: I use "Artist ~ Year ~ Album.ext". Notice the (~) tilde? I've never run across any names, etc... that use it, so for a delimiter it's great.

Embedding cue sheets: Personally, I don't embed because it's difficult to update after the fact.

ReplayGain: Forget messing with it for images unless you want to get involved with WaveGain. Let Foobar handle that one.

Here's how I have my music library setup:
\Music\Lossless\Artist ~ Year ~ Album\Artist ~ Year ~ Album.ext (Images)
\Music\Lossy\Artist ~ Year ~ Album\Artist ~ Album ~ Track ~ Title.ext (Single files)

Thanks for all your hard work Nitro322. You've put together a nice little tool

I hope you don't mind, but I've made a few enhancements as follows:

- Added user-definable naming scheme.
- Added user-definable meta-file prefix.
- Added option to store the disc number seperately in the tag instead of merging the disc number and the track number.
- Fixed a bug in detecting the end of the compression queue.

I wanted to be able to use a non-default path in my naming scheme (e.g. "Artist\Album (Year)" instead of "Genre\Artist\Album"). My changes basically add almost complete flexibility to the naming scheme, as long as the track number is the first element in the file name (after the elements defining the path). I couldn't find any easy way of obtaining the track number other than from the filename. To go along with the flexible approach, I also made the meta-file prefix user-definable (e.g. "00 - " instead of "00-").

Another thing I noticed was that the disc number was not being stored in the tag for multi-disc sets. So, I added an option to do this, instead of storing the disc number and track number merged together in the track number tag. The files are still renamed as before, it's just the tag that changes.

Finally, I encountered a bug where sometimes AutoFLAC would think that the compression cue was finished when it actually wasn't. This caused some problems, as you can imagine! So, I added a bit of extra logic around the code that detects if flac.exe is running, which seems to have fixed it.

I've numbered the modified version v1.0.2. An archive containing both the source and binary can be downloaded from here. I hope I've complied with the terms of the GNU GPL. Please let me know if I haven't.

I hope someone finds these enhancements useful. If anyone finds any bugs in my version that don't exist in the original, then please let me know and I'll do my best to fix them!

-Paul

masterofimages' fix took away my only reservation: not being able to edit the naming scheme. I hope this will get rolled into the official version.

Thanks Nitro322 for the script and masterofimages for the tweak.

I'm glad my enhancements were useful

I was toying with the idea of using another lossless codec (e.g. WavPack), so I though it would be nice if AutoFLAC could support any codec. So, I moved all the codec-specific settings into an ini file and added some settings for WavPack and True Audio. Adding support for new codecs is now simply a matter of adding a new section to the ini file. Version 1.0.3 of AutoFLAC can be found here. Maybe this multi-codec version should be renamed AutoFoo?

There's a one-time configuration step required before you can use the new version. That is to edit the ini file and change the path for each codec to match your system. Once this has been done, just select the codec from the drop-down, load the matching settings in to EAC, and off you go!

If anyone can find a command-line tool to do the multi-disc track and disc number retagging for WavPack and TTA, or to perform ReplayGain analysis for TTA, please let me know. I've left the relevant fields in the ini file blank for now. AutoFLAC will still work without them, but the relevant options will be disabled for those codecs. Enjoy!

-Paul

MOI:

I've tried various times over the past couple of days to download your modified version(s), but I always get a connection timed out error. Anyone else able/not-able to download it?

Update: tried from my local machine, as well as a `wget http://tranquillity.force9.co.uk/tools/autoflac103.rar` on a linux server on the other side of the US...still no connection.

-brendan

Hey, sorry about that. The correct URL is here. I should really remember to check it next time, but it was late

The link for v1.0.2 was correct though. Don't know why you had a problem with that one...

EBKAC, probably.

-brendan

I am getting the following problem with AutoFLAC:

http://philaphonic.spymac.com/Error-01.png

What is going wrong? Can I fix this error on my end?

This error is because AutoFLAC is unable to write to the cue file. It will happen if the AutoFLAC naming scheme does not match the EAC naming scheme. e.g. I can reproduce this error by setting my EAC naming scheme as "%A\%C\%N - %T", and my AutoFLAC naming scheme as "%A\%C (%Y)". The AutoFLAC naming scheme in this instance should of course be "%A\%C".

-Paul

Hi, Paul. I don't mind at all. I think some of these changes are very good ideas that should certainly be a part of the program. In fact, I've already implemented a couple of them in the development version. Some of the others, such as the variable naming scheme, will likely be copied over. Since this was originally developed to meet my own needs, I of course went with my own naming scheme, etc. I'm sure there are a lot of people that have different requirements, though, so additional flexability is a very good thing.

However, one thing that I'd prefer not to do with my application is have an external config file. I know that this is simply a matter of preference, but I'd prefer to have all options set through the GUI. As I said above I plan on incorporating many of your ideas into my version, but I most likely will not use an .ini file.

If you (or others) prefer this method, you're more than welcome to continue developing your own version. This is GPL'd software, so you have every right (as well as my blessing) to do so; however, if you go down this route, I do have a request. Could you please rename the application to something other than AutoFLAC? You can use a variation of it, or even AutoFLAC itself as part of the title, but I'd like there to be a distinction between my original version and any 3rd-party releases.

To everyone else: as mentioned above, I have been working on a newer version with some additional flexability and bugfixes. It's been a slow process, though, since I've been busy with work and out of town a good bit. I'm hoping to get something out by this weekend, though, so please stay tuned.

Regarding forks (or sporks*): instead of upping the version number or subnumber, I'd recommend the method of appending initials to the version used as a base, and then appending your release #s based on that.

This also helps to prevent version number conflict and the resulting user confusion regarding the primary stream vs. tributaries.

Granted, I haven't contributed code to this, so what do I know?

-brendan

* forks that are destined to curve around and be re-integrated, of course.

Thanks Nitro. I have a new version with some bug-fixes and little enhancements which is almost ready. I'll make it available shortly and, as you suggest, change the name. This makes sense, since my branch is no longer restricted to FLAC.

As for the ini file, it was the easiest way to provide the flexibility to allow the compressor options to be changed and extra codecs catered for. I would be happy to provide a GUI interface to these options (which would just read from and write to the ini file) if anybody really needed it, but I didn't think this would be worth the effort, since the file structure is pretty straightforward. Obviously, if your version is going to remain focussed on a single codec, an ini file isn't really necessary.

I'm looking forward to seeing what goodies your latest version will bring.

As promised, a new version (1.0.4) of AutoEAC (sic) can be found here.

Changes from AutoFLAC version 1.0.3 are as follows:

• Script renamed to AutoEAC.
• Fix for "Subscript used with non-Array variable" error when working folder not the same as script folder. This allows AutoEAC to work as an auto-insert handler for Audio CDs.
• Added explicit check for existence of ini file.
• Apply replaygain seperately to each disc in a multi-disc set (original behaviour can be re-activated by ini setting).
• Replace/trim invalid characters in rip directory to match the way EAC processes invalid characters.
• Don't close EAC if errors are detected and user clicks cancel to fix them.
• Save data track for each disc in a multi-disc set to a separate folder (defaults to "Data (Disc n)", but can be changed in ini file).
• Check first and last tracks for data track.
• Detect and report AccurateRip errors, and append AccurateRip results to log file.
• Added status area to AutoEAC window. AutoEAC now remains open and deactivated during processing, allowing relevant status messages to be displayed.

To override the default behaviour of multi-disc replaygain processing or multi-disc data track processing, simply remove the comment (";") from the relevant line in the ini file, and set the value as required.

Enjoy

-Paul

Paul, I have a few questions about your latest release, if you don't mind.

1) What do you mean by the "Subscript used with non-Array variable" above? When does that error occur?

2) I see the list you're using in the GetRipDir() function, but where did you get this information from? Eg, how do you know that this is EAC's behavior? This has been on my todo list, but I'd like to check it against an official source.

3) If I'm reading your code correctly, it looks like you simply added a check to see if the data track is listed as the first track rather than the last track. Is that correct? Have you seen this behavior? I've only ever seen it as the last track.

4) What exactly does your AccurateRip option do? It's always grayed out in my GUI.

Thanks!

It occurred when running AutoFLAC with the working folder set to a folder other than the folder containing AutoFLAC.ini. It only happened on the version with the ini file, due to the ini file not being found in the working folder.



Trial and error. I just ran test rips using all the invalid characters and used that to build a translation table.



Yes, I have at least one CD where the first two tracks are data tracks.



If set up correctly, and the CD you are ripping is in the AccurateRip database, a report is displayed at the end of the rip showing the accuracy of the rip (by comparing track CRCs with the AccurateRip database). I check this report for "rip not accurate", close the window if AccurateRip doesn't report any errors, and append the report to the end of the log file. When you insert a CD on the AccurateRip database you should see a little icon of a disc with a tick appear on the bottom right of the main EAC window. If the report does not display after ripping, you may have some EAC options set that prevent AccurateRip from working. E.g. I found that I had the "trim leading and trailing silence" option set, which prevents AccurateRip from obtaining an accurate CRC, and therefore disables the report!



My pleasure

-Paul

I just released version 1.1 of AutoFLAC. Please see the original post for details and download links.

Few notes about the release:

• The main focus of this release was adding support for FLAC images. This includes embedding the cue sheet and other related goodness. I still feel that individual tracks are the best bet for flexibility, but since this was a popular request, here you go.
• You'll notice the "Use Encoder" option in this release only lists FLAC. Currently this is still all that's supported. I added this option as part of the GUI redesign (actually, it was about 6 or 7 redesigns before I finally settled on this one), but WavPack will not be supported until a future release.
• This release DOES NOT support a variable naming scheme. I know this was another popular request, but I just haven't gotten to it. I do hope to add it to a future version.

On a related note, I've been giving some thought to masterofimages' port (AutoEAC). It has quite a few features not found even in the new version of AutoFLAC. Some of these I may still add to AutoFLAC (such as the variable naming-scheme), but others I won't. This would include the ini file support, leaving the GUI open while ripping a CD, etc. I could go into a long discussion of why, but my basic rule is that if it changes the underlying functionality, then it likely won't be added. An .ini configuration file is a good example of this.

So, masterofiimages, if you're cool with it I'd suggest continuing development of your version independently of mine. I think your version will provide better flexibility for people with different requirements than myself. Of course, I do plan on continuing to improve my version, and you're always welcome to use code from any future version. Hopefully you won't mind if I do the same.

Guess that about covers it. If anyone tries out the new version I'd appreciate some feedback on the changes.

BTW, Paul, would you mind if I link to your version from my AutoFLAC page? I'd like to present it as an alternate option. If that's ok, do you have any kind of home page for it, or should I just link to this forum?

Thanks.

I played around with both versions last night. Some things/questions that I had problems with and would like changed:

1. Every time I ran AutoFLAC/AutoEAC it would ask me to manually put in the directory the eac.exe was contained in. I don't have my EAC in a standard install directory and would appreciate being able to not have to put in the directory every time I run AutoFLAC/EAC.

2. I mainly like these programs for their automation with EAC's .cue sheet CD writing. One problem I have is that all of my .cue sheets have had the .wav extensions renamed to whatever lossy file type I have ripped to. AutoFLAC/EAC appends .flac/.wv to my already existing correct extension. It would be nice if there was a check in the program to determine whether or not the cuesheet already has the correct file extension or if it needs to be changed. This is rather nitpicky, but it would make things easier. I actually plan on using one of these programs for burning CDs via EAC, but I would not want to change all of my cuesheet extensions again


I haven't ripped anything with either of these programs as I use REACT and am comfortable with that. Further refinements to the CD writing portion of this program are always welcome!

Hmm... It should remember the path after you enter it the first time and rip a CD. If it's not then there's a bug in the code. I'll look into it.

For reference, can you please let me know A) where you have it installed, and B) how you installed it (installer, zip file, etc.). I'd like to replicate your setup.


That certainly makes sense. As originally designed this was intended to write back the CDs that it ripped. Since it's doing both the ripping and writing, it expects the format to be a certain way. This was definitely the easier way to code it, but things may break (obviously) if you try to write CDs backed up with another application.

With that said, I certainly think this is a reasonable request. Can you send me one of your cue sheets to review? I'll try to figure out a more generic way of implementing the write functionality.

That's cool. I don't have any plans to make any immediate changes to AutoEAC, but if someone make's a request for some new functionality, I'll do my best to oblige



Please feel free to link to my version. I don't plan on having any kind of home page for it.

-Paul

Are you referring to EAC or AutoFLAC? I'm not at my own PC right now to get you the exact directory I installed EAC in. I just ran AutoFLAC from my desktop unzipped to a folder. My EAC was installed using the .exe, but I changed its directory to something like C:\Program Files\Exact Audio Copy\

Just extract a cuesheet from any CD and rename the .wav file extentions with any text editor to .flac. Then drag that to AutoFLAC to write it and then you'll see the behavior I'm talking about (using non-compliant cuesheets btw).

I have a small request. I love your program btw. I like making par files when doing my backups. Is there anyway you could add an option to make par files if we'd like. Not sure if you can let us define our own commandline for it. I usually use this switch: par2.exe c -s640000 -r10 on my image backups. Thanks for any info.

FYI, once AutoFLAC or AutoEAC support Image extractions, acdir can be used with the -hidden-track1 option, to pipe wav data to other encoders (similar to how REACT works) to allow hidden track extraction.

-brendan

AutoFLAC 1.1 does support FLAC images. I've never heard of acdir, though, so I'm not sure how exactly that'd work

madxcream, I'll keep that in mind for the next update.

Oops, sorry, memory playing tricks.

acdir.exe will take a disc + cue image (WAV, FLAC and a couple of other formats), and can pipe each tracks worth of audio to encoders that support stdin as a source for audio. This allows you to create all of your lossy tracks in one invocation:

http://nyaochi.sakura.ne.jp/xoops/modules/...wares/tc_2.html

REACT uses this capability to perform its "FLAC Image + xxx lossy tracks" magic. Here's the invocation from the REACT's FLAC_MP3-image.txt config file (including REACT variables):



You point acdir to the output directory/extension, the encoder/options and the source cuesheet. It does the rest. And as I mentioned above, adding the -hidden-track1 option will pull the track 01 index 00 audio out as a separate track if it exists.

-brendan

First off, thanks to both of you for your work on AutoFLAC and Auto EAC. Great stuff! I am starting to think that, if I am going to rip my 900 discs, perhaps I should do them to FLAC images for archiving and then use Foobar to transcode them into individual lossy files. I am wondering a couple of things, though. First off, I truly love the idea of the gui for setting things up. I tried React and FLACattack and couldn't figure out how to make them work right.
Question 1: With AutoEAC, I am having the same problem as Philaphonic

http://philaphonic.spymac.com/Error-01.png

You said that it was due to the naming schemes being different in AutoEAC and EAC. I actually cut and pasted the naming scheme directly from EAC into Auto EAC. They both are :%I\%A\%Y\%C\%N-%T
Am I doing this incorrectly? No cue is being written.

Question #2 This is my functionality request. If you could
A: allow the naming convention in AutoFLAC to be changeable,
B: allow encoding with Lame or other codecs as individual files (while still encoding the FLAC images) into a different directory at the same time.
C: make certain that all data tracks and hidden tracks are included in the image.

this would be amazing!

These may be asking way too much. Thanks either way!

bump