Just curious, are you intending to add 'test and copy' support to the next update of AutoFLAC?

It's on my list of items to explore, but I don't know if it will be implemented in the next version or not. It mosly depends on how much time it will take to implement.

For anyone interested, this is what my current todo list looks like:


The stuff at the bottom has already been implemented. And no, order doesn't necessarily indicate priority.

Can anyone explain how the Test and Copy functionality is supposed to be used? As far as I can tell, the only difference between "Test and Copy Selected Tracks" and "Copy Selected Tracks" is that the former adds a line similar to the following for each ripped track:


Is that all it does, or am I missing something? I know there was a bit of discussion on this topic a few posts back, and I think I understand the technical details behind it, but I'm trying to figure out how exactly I should implement something like this now.

The only thing I can really think of doing would be to scan through the log file and report any tracks with different values for Test CRC and Copy CRC. I already do something similar for the files that report a "Suspicious position." Would this not essentially be duplicating that?

I have the same basic question for AccurateRip as well. It's been a little while since I used it, but if I recall correctly all it really did in terms of ripping is add another line or so to the log file. I've seen a couple people request AccurateRip support, but how exactly can/should AutoFLAC support this?

Thanks.

Ok, one last question for tonight. Another request that had been previously made was for par2 support. However, after playing around with this for a bit, I'm not sure how I could implement it in any way that would provide value.

This is actually very similar to my experiments with MD5. In both cases, I could create the support files easily enough, but if you edit the tags of any given song, it'll fail verification. So, let's say you create a checksum or set of parity files, and at some point in the future you want to burn the CD so you perform a verification. If the verification succeeds, you can be certain that you have a good set of files. However, if the verification fails, you cannot be certain that you have a bad set of files. You simply may have noticed an error in the tags and corrected it (which is something I do on a fairly regular basis, despite being as careful as possible while ripping). Or, you may have added a tag after the CD was originally ripped (eg, a PERFORMER tag on a particular track with a guest vocalist).

So, as with the MD5 checksum, I'm having a bit of trouble understanding how they could be usefully applied with AutoFLAC. Ideally I'd want to be able to create some kind of integrity file(s) on rip. then verify the integrity before writing. However, both MD5 and par fail this, at least as far as I'm able to tell. I suppose there would be some value in having a set of par files in case one of the originals gets deleted or damaged in a file copy, but I'd be hesitant to implement functionality like that just in rip mode because it'd give a false impression that it'd be later verified in write mode.

Any thoughts on this?

First of all, thank you for doing this.

I just tried it. The AutoFLAC subdirectory gets created just fine.

The problem is, the FLACs are not getting created. This is a cut-and-paste from the debug text file.
When I paste this into the command line, I get the following error:


So that makes it easier to figure out. I guess escape characters are getting munged somehow, but I'm not sure why it happens on one machine and not another. I have EAC installed in "C:\Program Files\Exact Audio Copy" and the FLAC binaries are in the same place. If I manually replace the Windows "short name" like this


(and then the rest of the command line from the debug text) the wave file is created properly.

More info: If I cut and paste this into the command line, it works (notice the quotes around the pathname to the flac executable):
The one below doesn't work--with the cmd pathname ahead of the quoted pathname to the flac executable--I get the same 'not recognized' error as above):
I hope this helps!

Damn, so it was my fault after all. I found the problem, and it should be fixed now. I've uploaded a newer copy of AutoFLAC to my website that contains the fix (and still includes the debugging code for now).

Cutestory and vhroxu2, can you please download the new test build below and try again? If it still fails, please let me know and post the debugging output one more time.

Everyone else, I took a crack at implementing a variable naming scheme. I've done a fair amount of testing and I think I have all the bugs worked out, but it could really use a little real world testing before I release the next final version. Anyone interested in doing a little beta testing? If so, please download the test build below, try out the variable naming scheme, and post your feedback.

Note: this is a beta release, and is not intended for production use: AutoFLAC 1.2 beta

Edit: I forgot to include the beta changelog:

Test and copy basically rips each track twice and compares the CRC values. In theory, if the two CRC's match then the saved copy is identical to the original CD.

Here is a link to an excellent ripping guide. http://calonet.org/eac
The extraction method and drive offset are crucial to obtaining a bit-perfect 1:1 copy of the original disc, the extraction method being the most crucial. "Test and copy" [F6 or Shift-F6] is most important for worn discs, but in trading circles, you can't always trust the ripper 100%. Who really knows whether the original is worn or not.? Thus the need for the "Test and Copy" CRC's in the log file.

It's alive!

(That means it's working.)

Variable naming scheme seems to work as well.

Another question (bug?). This has been happening for a while now, and I keep forgetting to ask about it, mostly because I was worried more about the problem you just fixed.

When there are characters in an album name like a colon, the logs and cuesheets don't get moved properly...they end up staying in the EAC working directory. In the actual directory, I get a cue sheet called "00-Albumname," and it is blank. Once I move the CUE sheet and log from their improper place into the album directory, I get the same error I was getting before...WAVs aren't getting created, and I can't write out the disc.

I have a workaround, which is to remove colons and ampersands from album names when I'm ripping them. Is there another solution?

Thanks again for all your hard work, nitro!

So then I should just tell AutoFLAC to start ripping with Shift-F6 rather than Shift-F5 is Test and Copy is enabled? Is that it?


Excellent, thanks for the feedback.


Ok, I find this a bit puzzling. One of the new features I added to version 1.1, based on some of the work masterofimages did for AutoEAC, was to replace special characters that the Windows filesystem won't support with characters that it would. Specifically, this is the mapping table:


So, any colons would be replaced with a hyphon, any slashes would be replaced with a comma, etc. This was done because EAC itself does this automatically when writing out files, whereas AutoFLAC (originally) just used whatever naming information was entered by the user. This would lead to file not found error message because the names wouldn't match up. The replacement code above is supposed to fix that.

Obviously, though, it appears that it's not working. I haven't encountered this myself, and this is the first I've seen someone else mention it, so at this point I'm not sure where the problem would be. Can you give me an album and/or artist name that causes this problem. I'll do some testing on my end and try to replicate it.

Yes, exactly. But I suppose the user should have the option, though I never use F5, just as I would never rip in Burst mode.

Hi

I have a small problem, hopefully you all can help.

Installed EAC and AutoFLAC, as per the instructions, including the file paths. All works OK.

Then I modified the file paths in EAC; it now looks like: %A - %C\%N - %T
After this mod I can rip OK but on completion instead of asking for next CD I get this message:

Line 0 (File d:\......\Autoflac.exe)
filewriteline($new, $line)
Error: invalid file handle used.

Is Autoflac hard coded to the filepath in the readme file ?
Or if not, what else could cause this?

Thanks

Yes, the current stable version has the naming scheme hardcoded. It was originally devevloped using the naming scheme that I personally use. Variable naming has been a popular request, though, so I've added support in the development version.

I've released a beta version that includes this support if you're interested in testing, though the code is very new and I've only received testing feedback from one user besides myself. If you'd like to test it out, you can find a download link in post 106. If you do decide to try it out, please post any feedback here so I know if it works for you.

I also get "Invalid file handle used" but I have done everything as it says in the readme (I think . It occurs when "analyzing track Gaps" (I get the text in swedish, so it might not be the exact phrase), at different tracks (out of 19)... it continues to analyze gaps, but the ripping doesn't start.

Please help, I'd really like to get this working.

EAC 0.95 beta 4, and the latest AutoFLAC.

OK so I tried the beta. It seem to get a bit longer, but this time I get this:



Still no ripping. I have not changed anything in the autoflac settings.

OK I'll try it and let you know.

Thanks

This error message means that it cannot find metaflac.exe. Make sure that the "Metaflac binary" option points to a valid copy of metaflac.exe.

Yes, well.. of course it does. I've tried putting it in the EAC catalog in Program Files, and also in C:\FLAC in case there is some spacing problem. No success. I have pointed it out using Browse, so I just can't see how I could have failed that one...

Edit: I'm sorry if I was unclear - what I meant by "not changed anything" was in the file naming area, where brianabbott had problems. The paths should point to valid directories, and I've tried every combination of paths with and without spaces in that I can think of (well, that's not much, but anyway). I can't seem to find any debug file, let me know if there's anything I can do to help.

Hmm... that's very odd. I've made quite a few during testing and development of the next version, and I have yet to encounter that problem. Off the top of my head I'm not sure what could be causing it. Let me give it some thought, and I'll get back to you tonight or tomorrow.


Hmm... if it's a naming issue, I think you should get an error message before that point. However, this is still very new code (obviously), so it's certainly possible I introduced a new bug that I haven't found yet. Again, let me think about this a bit and I'll get back to you.

In the meantime, could you please post the contents of the naming scheme fields in EAC (both regular and Various Artists) and AutoFLAC (both regular and image)? Also, how are you ripping your CD? Is it to individual files or an image? Is it a regular or Various Artists disc? All of this could potentially play a part.

Finally, the debugging code was only added to test converting FLACs to WAVs in preparation for writing. It won't be created when ripping CDs.

Will do, when I get home. I don't think I've changed any of the naming schemes, and I think I have followed the directions in the Autoflac Readme - I've even double checked it, but that is no guarantee it's right of course.

I'm ripping to individual files. Regular disc - I've tried several, with the same result.

A small suggestion: display the directory name that is invalid in the error box.

I can of course start the ripping process manually within EAC even after the error.

(Edit: Added information)

Been away for a while. Nitro, I tried the new beta autoflac, and I'm still getting the same "error cue sheet - line 7 doesn't exist" BS as before. Also, there's no debugging text file.

Calgot, I just re-read your original post, and it finally occured to me what's causing your problem - AutoFLAC is specifically checking for English phrases in the title of the application. There are several points where AutoFLAC needs to wait for new windows to appear (or disappear), and the only method I've been able to come up with for this is searching for window titles. If the English titles are not present, then AutoFLAC will fail.

This is something I'll need to address in a future version. In the meantime, could you try running the English version of EAC and see if it works as it should?


I wish I could, but that's an AutoIt fatal error, not a user-generated error message. The difference is that I only have control over the user-generated error messages. I really wish that wasn't the case, but there's nothing I can do about it.


Hi, vhroxu2. Welcome back. Are you sure you're using the beta version that I have posted in this post and not the latest version posted on the AutoFLAC website? The way it's coded, it has to create that debug file before it tries to load the CUE sheet into EAC.

Please double-check that you're using that version and run it again. You should get some debugging information written out to c:\autoflac_write.txt. That path and filename is harcoded, so it won't be anywhere else.

Works like a charm. Thanks!

Now if you could integrate AlbumArtAggregator or something somehow too....

Glad to hear it. I won't be able to add multilingual support for this version, but I will add it to me todo list to explore for future versions. Thanks for bringing this issue to my attention.


Well, that's what this script is for. Yeah, it'd be nice if it integrated with AutoFLAC, but there's a whole mess of PHP code in there that I just don't plan in porting over to AutoIt any time soon. I store all of my music on a Linux file server on my home network, so it's easy enough for me to SSH to my server and run this script after I copy the files over.

OK - I used the beta version listed in the post you linked to. It ripped the disc fine, but does it write the cue sheet or do I use the other version to in write mode? Sorry if this is a dumb question. I used the previous version in write mode, and I'm back to square one.

My understanding is that you were having trouble with write mode, which is one of the reasons I released the beta version - to add some debugging code for both you and Cutestory. Both of you reported similar problems when trying to write one of your ripped albums with AutoFLAC, so I want to make sure that the next version fixes those issues.

So, what I'm asking is that you use the beta version to try doing whatever it is that version 1.1 was failing on. Like I said above, my understanding is that this was on writing a disc - specifically it wasn't converting the FLACs to WAVs before loading the CUE sheet into EAC for writing. The debug code will print out line by line what it's trying to do when converting those files, so this will let me see exactly where it's failing on your system. I already made some changes there based on Cutestory's feedback, though, so hopefully it'll just work now.

Does that make sense?

Ok, I'm finally ready to release the new version. However, there are some fairly substantial changes and additions in this version compared to the last, so I'd really like to get some extra testing in before releasing the final version. I've tested it as much as I could, but since I usually don't use many of the features I added for this release (such as variable naming), my test cases may not be sufficient to uncover all possible bugs.

So, I'm going to release one more beta version. Actually, I'd call this a Release Candidate. It's feature-complete and should be stable. Just to make sure, though, I'd really appreciate it if a few of you could download it and give it a try on a couple CDs. Assuming no serious issues are reported, I plan on releasing the final version late Sunday night.

Here's the RC build: AutoFLAC.exe 1.2 RC

Please report back your results. Thanks.

Here's a list of the features most in need of testing:

I just released version 1.2. Nobody posted any issues with the beta version I posted, so I just have to assume that it works fine. I actually did catch one mistake in my own testing (some debugging code that I left in), but it only cause an annoyance and not any problems.

Anyway, I updated the first post to include download links and changelog information for the new version. You can find additional information on the AutoFLAC home page. Enjoy!

thanks nitro - I'll be checking it out later this week!

...

Hmm the URL above for the AutoFLAC home page appears to be giving a 404: http://www.legroom.net/mysoft/

-brendan

D'oh! I fixed it. Had an extra slash in there. Thanks for letting me know.

The test and copy is FANTASTIC! Great job, Nitro.

I am having a very slight problems with the naming scheme, however.
Base Directory is "K:\EAC"
Name scheme is "%A - %C (%Y) [FLAC]\%N - %T"

These match their settings in EAC Options under the Filename and Directories tabs. The problem is that the CUE file is saved in the base directory, K:/EAC, instead of the rip folder and has a path statement in the file name, which matches the Name scheme above. I might add, this is typical behaviour for EAC and has nothing to do with AutoFlac. If you use EAC without AutoFlac, the same thing happens. If you leave the path out of the naming scheme, no issue with path in the cue file, and the cue is created in the rip folder, with or without AutoFlac.

Someone might suggest to then set the variable path "%A - %C (%Y) [FLAC]" in the Base Directory, but this is not possible, it must be a valid existing directory. Addtitionally, one can easily edit the CUE and move it to the rip folder as the easiest workaround. Or, one could just bypass the folder creation altogether and move the files to a new folder. Better to have the variable file naming scheme than nothing at all.

I really don't think there is a solution to this, but who am I to say. Hell, I'm thrilled to have Test & Copy support. But we strive to achieve perfection. We are Borg.

Another small thing. I don't see a setting to create a FLAC CUE file. The program now appears to make a WAV CUE by default. I guess this is OK and more traditional behaviour, but one must then edit the WAV CUE in order to use AutoFlac in Write Mode.

Ideal behaviour would be for the program to write TWO cues, both FLAC and WAV, but beggers can't be choosers, as they say. I have always done that manually or within the program for "Burrrn" purposes.

I was hoping that Test & Copy would miraculously work for image creation, but it doesn't. EAC does not support this yet, but one can always hope. FLAC CUE creation still happens for image creation, folder creation does not. No surprise.

Grade: A-

EDIT: I missed the part about "Added support for writing CUE sheets that specify .wav files rather than .flac" This works great with no addtional user intervention. With "Burrrn" there is an extra step involved.
Grade now a solid A. You get an A+ if you figure out the cue sheet path and location problem, but I'm not holding my breath. That's an EAC issue.

Try setting the name scheme to just the directory portion of the EAC naming scheme. Eg:
%A - %C (%Y) [FLAC]

AutoFLAC has not control over or even visibility into the actual file names, as this is handled entirely by EAC and flac.exe. So, you'd want to specify the full directory and filename info in EAC's configuration, and specify just the directory information in AutoFLAC so that it knows where the files are and can update them accordingly.

I attempted to explain this in the help information (the ? button to the right of the naming scheme), though I'm not sure how successful I was. If it's unclear, please let me know.


I don't follow you here. What's a "FLAC CUE"? The .cue file that gets written should be directly usable by AutoFLAC in write mode (or foobar2000, or any other FLAC and cuesheet aware application), without any modification. The only difference between it and the standard .cue file that EAC outputs is that the filename extensions get changed to .flac rather than .wav, so that it points to real files. Can you explain in more detail what you need to manually change and why?


I don't quite follow you here, either. The only tangeable result of Test and Copy, as far as I can tell, is that an extra CRC value for each track gets written to the .log file. If this mode is enabled, AutoFLAC will then scan for these CRC values and report any differences. Otherwise, it behaves exactly the same as the normal Copy mode. What do you mean that "EAC does not support this yet?" What's missing?

Also, what do you mean by "folder creation does not" happen for image creation? It should, according to my testing. Can you give me an example where it fails?


Glad it's mostly working for you. And thanks for the feedback.

First off, thanks for this great program!

There are a few little things that I'd like to see in this great project of yours

1) The ability to have a custom syntax for .CUE and .log files too. The "scene-like" 00-xxxxxx syntax isn't down to my preference, really. I like the normal EAC way more.

2) The ability to save the accurate rip info. (I might be missing something though, since I might have read something about something like that)

I'll keep this in mind. How would you prefer it? How does EAC do it by default (I haven't used EAC without AutoFLAC for quite a while now)?


Can you please reply to my comments about AccurateRip in post 103? I'm not opposed to it, just don't know what exactly is needed.

Thanks.

Ok, since you asked (well, you didn't ask *me*, but I'm jumping in anyway)...



AccurateRip adds several lines to the logs, at least one for each track. It basically lets you know if the audio data you are ripping is bit-identical to other folks ripping the same CDs.

So, while AutoFLAC could simply just log the data for completists out there (hi), here's another idea that might be useful, though you may feel it to be overkill: use the results of T&C, AccurateRip or "suspicious positions" (or even combinations of the results since AccurateRip isn't always available) from an initial Burst Track T&C rip to tell AutoFLAC whether to re-rip some tracks (in track mode) or rip the image (in image mode) using secure mode instead of burst mode.

Specifically...

In Track mode: Burst rip the disc using and if the results do not show good results, change the rip strategy from Burst to Secure and perform the rip again...perhaps do this only with the Tracks that did not show good results. In addition, add the initial and final AccurateRip information to the saved log.

This would be automating the typical user behavior of using burst mode until errors are reported, then reripping using secure mode.

In Image mode: unfortunately, I don't think EAC has support for T&C in Image mode yet, and AccurateRip does not currently work with Images. With that said, they might still be useful: perform a Burst TRACK extraction first, discard the ripped data, but use the results to decide whether an Image extraction should be burst (T&C and/or AccurateRip showed good info) or secure (T&C and/or AccurateRip showed bad or questionable info). Reconfigure EAC if necessary, then perform the Image extraction.

This would be automating a less typical user behavior of using an initial track mode rip's T&C/AccurateRip results to gauge the likely quality of the Image rip the user is about to make.

-brendan

nitro-

One thing I'd love to see added would be a hands-free or autopilot ripping mode, where there are no prompts, just actions on disc swaps.

You already have an Eject on complete option. How much trouble would it be to detect Disc Insertion and run another extraction with the same options as the last one? If troublesome (I would imagine there might be an issue that EAC has a lock on accessing the drive), perhaps it would be better to look for EAC's own recognition of a new disc insertion as notification to move forward?

In addition, autopilot mode would convert some of the current msgbox prompts to notations in the logs (e.g. T&C errors detected), others to a simple Cancel button (e.g. "Insert another disc or press cancel to end.") so as to not require keyboarding between discs unless there was a serious error.

What are you thoughts?

I'd prefer not to fork your good work unnecessarily, but I can take a stab at it, if you'd like.

-brendan

Ok here's some info for you.

Here's the name of the album EAC reports: "Monsieur Gainsbourg: Revisited"

This is a Various Artists album.

The directory created in my working directory is:
\Various Artists\Monsieur Gainsbourg- Revisited\

At the end of the ripping process, I end up with two orphan files in my working directory:
"Monsieur Gainsbourg Revisited.cue" and "Monsieur Gainsbourg Revisited.log"

The forum font makes it difficult to see, but there are two spaces after the word "Gainsbourg" in each filename above.

In the \Various Artists\Monsieur Gainsbourg- Revisited\ directory, there is an empty file named:
"00-Monsieur Gainsbourg- Revisited.cue"

This is odd: here is the first line of the debug textfile (after manually moving the CUE sheet into the proper directory):
Looks like part of the pathname is being appended twice...?

I hope this is enough for you to go on, and thanks again for looking at this.

Edit: I tried just adding a colon to a CD that didn't have one (and wasn't a Various Artist CD), and got the same result.

1) EAC puts just the album name to the logfile and the cuesheet. For example 'The White Album.log'.

2) This is an example info that accurate rip can make. Although I have no idea how you can get that info since Accurate rip only shows a window with that info after the rip is complete.

The Accurate rip info was appended to the log in what became AutoEAC; that's currently the only feature that I miss...

Ok, I got fidgety. It's a bit hackish, and beeps annoyingly when you don't feed it discs immediately, but there you go:

http://brendan.org/public_files/AutoFLAC1.2_bgh1.au3
http://brendan.org/public_files/AutoFLAC1.2_bgh1.exe
http://brendan.org/public_files/AutoFLAC1.....2bgh1_diff.txt

I'm not planning to continue fork this, so I versioned it as a one-off. Therefore I used the AutoFLAC name, with my initials appended to the version number. It could quite possibly dead end at bgh1

The change is this: you should be able to rip discs consecutively without having to use the mouse or keyboard, or even look at the screen. When a disc is done, it will pop out and the computer will beep every 10 seconds. Swap a disc in, press the tray in (dealing with perhaps one more beep) and then that disc gets processed and ejected. Repeat...

The auto-rip timeout is hardcoded to 10 seconds because I am lazy and didn't want to deal with too many UI changes.

Autorip requires turning on the Eject on Complete function, To be nice, it automatically sets that for you when you enable Autorip. The checkbox line for autorip also begins a count down to autorip, automatically resetting back to 10 seconds any time an option is changed on the screen. If you disable autorip, the count down is disabled.

If autorip is enabled, and a disc is finished without error, you still get the standard dialog asking you to press OK to rip another disc. However, as I mentioned before every 10 seconds, the dialog closes, EAC is checked to see if a disc is inserted and, if so, we continue, otherwise we put the dialog back up again and continue checking and beeping every 10 seconds.

If autorip is enabled and a disc is finished WITH an error, the two types of warning dialogs (containing normal EAC and test & copy errors) will appear, but they too will automatically dismiss and check for new discs every 10 seconds. I didn't test this part of the code (ripping from daemon tools on this disc-less thinkpad, so I'm not able to test errors), so it might not work as well as I think it should. Let me know.

Oh yeah, when a new disc is found using autorip, you end up back at the config screen and since autorip is enabled, in case you do want to adjust things. But the countdown continues and autorip takes off unless you stop it.

I figure this will primarily be used for Image and All Tracks types of ripping while the user is busy handling other tasks and doesn't really want to deal with the keyboard/mouse.

Thoughts?

-brendan

PS - the beep every 10 seconds is an annoyance of the msgbox function, so I've decided to call it the "reminder feature".

Wow. This sounds pretty interesting, but I'm sure it'd take a really long time to implement correctly. It's a great idea, but I'm going to have to put it on my long-term ToDo list for now.


Is this really typical user behavior? I just rip using secure mode for everything (I really hate that term, by the way; ripping CDs has nothing to do with security. It should be called accurate mode or something like that. Anyway...). This method works fast enough on "good" CDs, usually averaging between 3.5x and 8x, and obviously you'd want to use it on "bad" CDs. Why bother with switching modes? What do you really again?


This is a neat idea. This is actually one of the things I really liked about abcde (a CLI-based Linux ripper) - it's very easy to rip multiple CDs back-to-back.

However, the big issue that see with this approach is with CD/track naming. It's pretty rare that I do a freedb lookup and don't have to change something, be it case sensitivity, removing special characters, stripping out a subtitle that may be included with the title, etc. Hell, I've even had to convert the language to English for some import CDs.

Since I WANT to see all of this information and verify that it is correct before ripping and tagging the CD, there'd have to be some stop in the process between CDs. That's why I have it prompt you to enter a new CD. I could probably skip a prompt in between there, but I'd still need something that waits for the user to ackowledge that the freedb info is correct (if the disc was even found in freedb).

To implement a true autopilot as you're suggesting would cut out that verification step. I guess that may work for some people that don't really care about their track names and tag information, but I'm VERY picky about mine. I would suspect that I'm not alone, either - if you're going to invest the effort in ripping all CDs to FLACs and preserving CUE sheets, why would you not want to verify that it's properly done?

I'm definitely open to more discussion on this, though. I also saw that you had posted something more about this below. I haven't read it yet, though, because I wanted to give you my initial thoughts first. I'll comment more below.


It should be possible to read that data and append it to the log. I already read through the summary report after extraction is completed to check for any read or sync failures. Doing the same but actually copying the data rather than reading it should be pretty easy.

However, I thought I recall AccurateRip information already saved in the log file. Is that not the case?


How did you handle the freedb issue I mentioned above? I'm assuming it has to just accept whatever freedb provides, right? What of the CD is unrecognized?


Yeah, major pain in the ass, isn't it?


Hmm... It's a pretty clever solution. You still give the user a chance to cancel it if necessary, or change options or whatever else may need to be done. I still have some reservations about it, and would definitely have to give it a good bit of thought before merging something like this into the "official" version, but overall I really like the implementation. Nice work.

I'll give you some more feedback, and will probably have some more questions for you, after I've had a chance to play around with it and really digest the idea. I've been busy with other stuff this past week, and will be out of town through the weekend, so I won't be able to work on this any until next week at the earliest.

CuteStory, I'm going to try to spend a little bit of time tonight looking into this. It appears to be an issue with EAC renaming the directory differently than the output files. The fact that it renames your files at all without telling you is bad enough - doing it inconsistently is just horrible. I need to do some additional testing to be sure, though, and make sure it's not it's not my own replacement function (which is simply an attempt to match EAC's broken behavior).*

In the meantime, could you please tell me if CDs without any special characters work for you? Eg., try ripping the same CD with the colon removed. I want to make sure there isn't anything else going on that could affect this.

Thanks.

Edit: After re-reading this it looks like I'm trying to fault EAC for this. I'm not one to play the whole blame-shifting game, but in this case I DO fault EAC for this. Programs should NEVER rename your files in some unexcpected and undocumented way without warning you. EAC neither warns the user about this (which would be very easy to do), nor does it tell you HOW it's going to rename the files (which is also very easy to do). I'll still try to work around it, because I'm more interested in putting out a useful application than pointing fingers, but I want to be clear on what the source of this problem is.

Not mine. This is similar to the way Plextools rips, but it [supposedly] implements C2 information accurately. The jury is out in that respect, but in any case, only Plextor drives would have any chance of using C2 accurately.

My vote is to not spend any time on anything having to do with Burst rips. What's the hurry?

A simpler thing would be to also flag all discs that showed problems and write that list to a sort of "meta-log" so you can set them aside and secure rerip them.



Speed primarily. The intersects wth the T&C/AccurateRip conversations on this thread as well.

Assuming your drive is in good condition, the T&C and AccurateRip features allow you to be confident about your burst reads for the majority of your discs that are also in good condition, and back off to secure ripping for those that showed issues in T&C and AccurateRip.



Ah, yes. I do not disagree about being picky about the metadata: I do care about the track names and tag information, *definitely*.

However, I do disagree about *WHEN* this should occur, at least for Image rips. The process of setting/correcting metadata should be decoupled from the ripping process, since it requires you to
wait (or stop some other task) constantly and deal with a novel issue on every disc. That kind of thing drives me nuts. I'm working on making the ripping process as brainless as possible (a reason I purchased Riptastic! last year, it has a batch mode that was pretty brainless, but I want to use EAC for secure ripping and accuraterip logging).

So, to my mind, metadata review and correction in the CUE sheets for image rips should be handled after the rips, which allows you to work on it all at once in tools that are probably better suited to this kind of thing and generally avoid dealing with discs, drives and ripping delays. It's a task you can power through when you are in the mood.



Thanks.



Explained above, at least for Image rips.
Yes.
I don't know.



As I said, the autopilot I implemented is more of a quick hack. I wrote/tested it while lying in bed last night due to insomnia. No, really! That's how it happened.

So, there are circumstances it won't handle I am sure, such as problems with freedb. Unrecognized discs will either convert to generic naming or get stuck, I haven't tested it. I should probably append the freedb ID in parenthesis to the filenames to ensure overwrites do not occur on missing discs or if the Internet disappears and you aren't running a freedb lookup proxy that goes to a local db first on your local machine.



Thanks again.

Some things I will probably change before you get back (bgh2 anyone?), but I am trying to keep the changes small:

The current open msgbox w/ 10 second delay, beep, wait, close, check for disc, repeat process is not really optimal. It really should be a custom non-modal control that acts like a dialog box, but that can monitor the disc inserts in near-realtime - and the beeping can be removed or made optional and/or less frequent. Plus, a pause/resume button should be added.

I should also change the options screen timer to use a separate field so the user can set the delay(s). I though the spinning down checkbox text was pretty cute though, but if you look at the code, it's silly crap code. Plus the $timer = 0 everywhere was stupid too, that's getting fixed pronto (I claim the insomnia defense!).

And something that I need to mull a bit more before figuring out the best approach:

I'd love to have the ability to capture the multiple freedb/cddb lookup matches (e.g. for small CD singles that tend to match multiple releases) as additional CUE files that can be saved along with the FLAC file, for quick-fixing later.

A hackish way would be selecting each of the possible freedb options one at a time and saving the info as CU0, CU1, CU2, CU3... file types, to be presented as the possible options to change one to a CUE by a script later, as the first part of the meta data correction phase. Yes gross, but prevents other applications from seeing multiple CUE files per FLAC image.

Or perhaps just a wait/notify on multiple matches if that's not the current fall-through behavior (i.e. quick fix). Similar for no matches.

EDIT: regarding the idea of using burst until secure is needed... I have ~9000 discs to rip, so speed is an issue. But I can see the argument against having to create a big blob of new code in order automate the good vs. bad analysis.

-brendan

Posted about an old issue. Never mind. Thanks for all of your effort!

An update, addressing the most annoying bits:

http://brendan.org/public_files/AutoFLAC1.2-bgh-2.au3
http://brendan.org/public_files/AutoFLAC1.2-bgh-2.exe
http://brendan.org/public_files/AutoFLAC1....-bgh-2-diff.txt

* 6. Add delay counter as editable field in options and use that instead of a hardcoded 10.
* 9. Change disc wait current msgbox to custom non-modal control. Solves beep problem. Allows for future enhancements.
* 10. Add Pause/Resume as a button to that replacement dialog.
* 11. Make new Pause button hidden if autorip is not enabled.
* 13. Make autorip timer stand out in red.
* 14. Prevent multiple copies of AutoFLAC from running at once.
* 15. Use a real timer instead of a counter in the main GUI - also reduces CPU usage during wait events.
* 17. Replaced several "="s with "=="s in IF statement conditions.

Unfortunately, I hit the code-tidy function, which ProperCased everything, so a precise diff will show a lot of non-functional changes. A case and whitespace insensitive diff helps to make the changes look a lot smaller.

-brendan

Yeah, I took the same CD and ripped it twice, the first time adding a colon to the album name and the second time removing it.

The first CD had the problem I described, the second CD ripped fine.

Ah. Colons aren't allowed in Windows filenames, as they're reserved for devices, I believe.

-brendan

Nitro - I couldn't get the beta to work for sh*t, so I downloaded the one from the website and guess what - IT WORKS LIKE A CHARM!!!!!!

Thanks a lot for writing this program and taking the time to help me through the problems.

Oops. Missed that. RTFM, I guess. Maybe on the next release, put that in caps or bold letters. No biggie, though.




The FLAC cue is a cue file using FLAC file extensions as opposed to WAV. I was wrong on this account. At first the program creates a WAV cue, in the base folder [K:\EAC in my case], but after ripping, this file gets converted to a FLAC cue and numbered with "00-" preceding the original file name. It also gets moved to the correct target folder and the original WAV cue is deleted. Pretty clean.

I'm with Nakkis as I'd prefer not to have the preceding "00-" but, again, no biggie. One can always edit the file name. Also, if you want to keep the original WAV cue, be sure to copy it into the target folder before the rip process is complete.





In EAC, Test and Copy ONLY works when you extract individual tracks. The purpose of test & copy is not only to have an extra CRC value, but to assure that these values match. The theory being that successive rips with matching CRC's have nearly a 100% chance of matching the original. The author of EAC has Test and Copy for image creation on his to-do list, but no one is holding their breath quite yet.

What I was trying to say is that in the opening AutoFlac pop-up window, it is possible to check both boxes for "Test and Copy" and "Rip to Image." But since EAC does not support T&C for image creation it doesn't work that way. Again, no biggie.



I've played around somewhat with the image naming scheme [though I would seldom use it myself]. Its not really clear how to set up these two parameters within EAC and the AutoFlac interface.

My settings in AutoFlac:
Base Directory: K:\EAC
Image Scheme: %A - %C (%Y) [FLAC]\%A - %C [Image]

This works correctly, the key being to add the file name into the Image Scheme box [just like is says when you press the "?" button]. The cool part is that not only does AutoFlac rename the image file with my "[Image]" added, it changes the cue file to match the file name as well! Brilliant!

Grade has been revised to A+

Here's a suggestion for the next version. In write mode, it would be nice to have no user input necessary after the extraction from FLAC to WAV.

I just started using AutoFLAC the other day. Im using FLAC to backup my cd collection. Ive backed up 5 cds so far. What i find interesting is it only takes about 4 minutes to rip and convert the files to FLAC. Is this speed unusual? When I used EAC in the past to rip and convert to MP3, it took 10+ minutes sometimes for a CD. I had a different drive back then, but I dont think it should make that much a difference. I just want to make sure I dont have some type of setting on that increases speed while reducing quality of the rip.

ALSO, all this talk about CUE problems, will this cause my FLAC files to be useless? Is there a way to save the CUE file in the folder the FLAC files are saved in? Example : ROCK\GROUP\ALBUM vs the root save directory?