Skip to main content

Topic: AutoFLAC 2.0 Progress (Read 6464 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • nitro322
  • [*][*][*]
AutoFLAC 2.0 Progress
Hello, all.

As any AutoFLAC users are well aware, development has been on hiatus for quite some time now.  The last release was just over three years ago, as discussed in the original forum post.  I obviously haven't given AutoFLAC the love and attention it deserves since then, but things have been rather busy and I just haven't had time for it.

The good news, though, is that I've recently resumed work on AutoFLAC and I've been quietly hacking away on a new version.  I'm pretty close to having a beta release available for testing, but I have a couple remaining issues to work out and I could definitely use some feedback from the EAC gurus on this board.

Before describing the issues, here's a list of the major changes in v2.0:

  • AutoFLAC will read as many settings as possible directly from EAC
  • AutoFLAC will check and optionally auto-configure necessary EAC settings
  • AutoFLAC is now fully compatible with EAC 0.99 and FLAC 1.2.1
  • Added verbose debug logging to assist with troubleshooting
  • Numerous other bug fixes and enhancements

The biggest change is the EAC "integration" (for lack of a better word).  As a result of this, the various UI options for setting the naming scheming, the location of the flac binaries, etc. have been removed.  Aside from making this easier, this should also make it much more reliable as one of the most common problems with discrepancies between the AutoFLAC and EAC naming schemes.  Also as mentioned, AutoFLAC should now be able to automatically configure a fresh EAC install for use with AutoFLAC, rather than making you manually following the somewhat tedious instructions in the readme file.

Unfortunately, this integration caused a couple of problems that I'm having trouble working out.  I'd appreciate any suggestions on how to address these issues:

1. EAC provides an unusual way to specify the CD-ROM drive used for extraction.  Instead of simply using the drive letter, it lists a mangled version of the full drive description w/ firmware (at least on mine) and SCSI bus information.  That apparently works fine for EAC, but AutoFLAC needs to know the drive letter being used, and I just cannot figure out how to translate the the EAC-provided drive description into a drive letter.  Any ideas on how to do this?  Some additional info:

The only info I can get about the drive used for ripping appears to be from the drive selection box in the main EAC GUI.  Eg., my drive reads "TSSTcorpCD/DVDw SH-S183L SB03  Adapter: 1  ID: 0", and that's all I have to go on.  EAC saves drives configuration information in the registry, but not drive identification information.

I can query the registry or WMI to get information about the avilable drives on the system, but I can't find anything that matches the EAC description.  Eg., I can get this: "TSSTcorp CD/DVDW SH-S183L", but notice that the spacing is different, and it's missing the firmware information.  I can't come up with a good programmatic way to parse this information or do simple string matching.

As a fallback option I can simple continue prompting for the CD-ROM drive letter in the AutoFLAC GUI, but I'd rather avoid that since everything else is being pulled from EAC now.

2. EAC saves the naming scheme for ripping separate tracks, but NOT the naming scheme for ripping images.  Instead, it prompts you to enter the image filename when ripping each image, defaulting to "%artist% - %album%.wav".  Unfortunately, I need some way for AutoFLAC to know this information before that point.  The best I've been able to come up with is to simply include the image naming scheme in the AutoFLAC GUI (as is done in v1.2), but that seems kind of silly since the other naming scheme is being read from EAC.  Any other ideas here?

That pretty much covers it.  I'd very much appreciate any feedback on this.  Also, if you've found any bugs or other issues in the previous version, please let me know and I'll try my best to include a fix for that as well.  I should also mention that I have access to a copy of Windows 7 now, so I plan on doing some extra testing on that to make sure it installs correctly, plays nicely with UAC, etc.  Again, if you've noticed any previous problems with Vista compatibility, etc., please let me know.  I'd like to make this release as solid as possible.

Thanks, guys.  Once I get these last few issues worked out I'm going to put out a beta for widespread testing of the changes, and then hopefully we'll finally have a (long overdue) new release before long.

AutoFLAC 2.0 Progress
Reply #1
About the CD drive identification issue:

So is it only a parsing problem? It looks like to me that the strings given by Windows and EAC are the same except for EAC having the firmware version and the Adapter: ......  in the end. The spacing and case sensitivity doesn't seem to differ (I assume they were typos in your post?). It looks like EAC's strings go as follows:

The stuff that is the same in EAC and Windows+space+4 chars of firmware+2 spaces+Adapter:+space+x+2 spaces+ID:+space+y.

That is - shared stuff+24 chars of rubbish. So after removing those 24 chars from EAC's string the strings should be the same.

I think it could be done with Java's built-in tools:

//some preliminary stuff probably needed
String EAC_drive=stuff given from the AutoIT Java bridge;
String Win_drive=more stuff given from the AutoIT Java bridge;

EAC_drive_new=EAC_drive.substring(0,EAC_drive.length()-24); // trim() can be used if spacing's a problem

if (EAC_drive_new.equals(Win_drive) ) // equalsIgnoreCase() if the case sensitivities can differ
    boolean stringsMatch=true;
//and so on...

I'm no pro, just a CS freshman, but I'm pretty sure it'd go something like this. Oh yeah, here's a link to AutoIT's Java UDF Library:
  • Last Edit: 02 March, 2010, 01:00:33 PM by chernobyl300

  • RolloTomasi
  • [*][*]
AutoFLAC 2.0 Progress
Reply #2
I have a couple of suggestions.

Force an F4 'gap detection' prior to making the cue file.  This will allow the gaps to be seen in the log file.  I mentioned this a ways back, but AFTER the most recent update.

It would also be nice to eliminate the "00-" at the beginning of the saved cue file, as well as them having the log, cue and m3u with the same file name.

No other issues to report.  The program is working great for me.

  • madxcream
  • [*][*]
AutoFLAC 2.0 Progress
Reply #3
How is this development coming on this? I love using autoflac. I am with the optiong to have autoflac detect gaps so I would not have to manually do that. Thanks for any info.

  • johnlgalt
  • [*]
AutoFLAC 2.0 Progress
Reply #4
Resurrecting a very old post, and I apologize, but am I right to assume that the 2.0 ╬▓eta version never came to fruition?

  • nitro322
  • [*][*][*]
AutoFLAC 2.0 Progress
Reply #5
Hi, John.  You're correct, it was never released.  Just never got around to finishing as I've been busy with other things.  I still regularly use it with EAC 0.99 (it's quite reliable with the improvements I made for 2.0), but it still needs some love and attention before it's ready for public release.  I can't make any promises, but I'll see if I can take a look at this again before too long and try to bang out something suitable for release.  If I can devote enough time to at least fixing the couple remaining major issues and updating it for EAC 1.0b3 then I think that should be good enough to actually release the beta, and then hopefully I can follow up with a polished 2.0 release at some point in the not-too-distant future.

I honestly didn't know anyone besides myself was still using it at this point.  Knowing that now does provide a little more motivation to (finally) get this done.  :-)

  • Ouroboros
  • [*][*][*][*]
AutoFLAC 2.0 Progress
Reply #6
I use it all of the time. Absolutely great, but a version that worked a bit better with EAC 1.0b3 would be brilliant. I had a quick look a few months ago to see if I could make it work a bit better, but concluded that it was more than a couple of afternoon's work to find my way around the source, so just reverted to using EAC 0.99.

  • nitro322
  • [*][*][*]
AutoFLAC 2.0 Progress
Reply #7
Yeah, I'm (obviously) still using 0.99 myself, but aside from the time involved in updating AutoFLAC there's another reason I haven't been in too much of a rush to update EAC to 1.0b3 - 0.99pb5 actually works well under Linux through wine, so I can rip my CDs directly in WIndows rather than having to launch vmware.  Sadly, EAC 1.x does not (as far as I'm aware) work correctly in wine.  Oh well.  Woe is me, right?  :-)

I just spent a couple hours working on this earlier tonight, the first time I've touched the code in quite a while, so that's good news.  I have EAC 1.0b3 installed now in vmware, so I'm going to try tackling that next.  Once I get suport for that working, I'll probably release the beta for some wider testing by anyone interested before wrapping up the last few items on my todo list.

Actually, I do have a a question regarding one of those final todo items:  I'd like to add accurate rip reporting/verification support.  To simplify things a bit, would it make sense to simply replace the Test and Copy feature with Accurate Rip?  or is there a good reason for people to still use Test and Copy instead of, or in addition to, Accurate Rip?

  • chelrob
  • [*]
AutoFLAC 2.0 Progress
Reply #8
Test and Copy is absolutely essential, especially if you're ripping a disc that isn't already in the accurate rip database. 

Please include both Test and Copy and accurate rip.

Thank you