Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: AutoFLAC (Read 326487 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AutoFLAC

Reply #25
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

AutoFLAC

Reply #26
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.

AutoFLAC

Reply #27
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

AutoFLAC

Reply #28
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

AutoFLAC

Reply #29
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?


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...



AutoFLAC

Reply #32
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

AutoFLAC

Reply #33
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:


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.

AutoFLAC

Reply #34
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. 

AutoFLAC

Reply #35
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. 


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.

AutoFLAC

Reply #36
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

AutoFLAC

Reply #37
Changes from AutoFLAC version 1.0.3 are as follows:
  • 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.
  • Replace/trim invalid characters in rip directory to match the way EAC processes invalid characters.
  • Check first and last tracks for data track.
  • Detect and report AccurateRip errors, and append AccurateRip results to log file.

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!

AutoFLAC

Reply #38
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?


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.

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.


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

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.


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

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


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!

Thanks!


My pleasure 

-Paul

AutoFLAC

Reply #39
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.

AutoFLAC

Reply #40
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!

AutoFLAC

Reply #41
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.

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.

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 

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.

AutoFLAC

Reply #42
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. 


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

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?


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

-Paul

AutoFLAC

Reply #43
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.

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\
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.

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).

AutoFLAC

Reply #44
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


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.

AutoFLAC

Reply #45
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

Reply #46
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.

AutoFLAC

Reply #47
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):

Code: [Select]
@encdir@\acdir.exe --overwrite --output "@destdir2@\%out2%.mp3" --pipe "@encdir@\lame.exe -V5 --vbr-new --scale @scale@ --add-id3v2 --pad-id3v2 --ignore-tag-errors --ta $#a --tl $#T --tt $#t --tn $#n --ty $#r{DATE} --tg $#r{GENRE} --tc $qAG applied: @gain@$q - $#o" "@sourcecuesheet@"


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

AutoFLAC

Reply #48
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!

AutoFLAC

Reply #49
bump