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 328902 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AutoFLAC

Reply #125 –
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:

Code: [Select]
Added support for variable naming schemes
Added GUI interface for write mode options
Added support for writing CUE sheets that specify .wav files rather than .flac
Added support for EAC's Test and Copy mode

AutoFLAC

Reply #126 –
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!

AutoFLAC

Reply #127 –
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

AutoFLAC

Reply #129 –
  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.

AutoFLAC

Reply #130 –
Quote from: RolloTomasi on
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"

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.

Quote from: RolloTomasi on
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.

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?

Quote from: RolloTomasi on
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.

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?

Quote from: RolloTomasi on
Grade: A- 

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

AutoFLAC

Reply #131 –
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)

AutoFLAC

Reply #132 –
Quote from: Nakkis on
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.

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

Quote from: Nakkis on
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)

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.
 

AutoFLAC

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

Quote from: nitro322 on
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?


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

AutoFLAC

Reply #134 –
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

AutoFLAC

Reply #135 –
Quote from: nitro322 on
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.
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):
Code: [Select]
C:\Program Files\Exact Audio Copy\flac.exe -d -o "M:\working\Various Artists\Monsieur Gainsbourg- Revisited\AutoFLAC\Various Artists\Monsieur Gainsbourg- Revisited\02-Cat Power & Karen Elson - I Love You (Me Either) (Je t'aime moi non plus) - Cat Power & Karen Elson - I Love You (Me Either) (Je t'aime moi non plus).wav" "M:\working\Various Artists\Monsieur Gainsbourg- Revisited\Various Artists\Monsieur Gainsbourg- Revisited\02-Cat Power & Karen Elson - I Love You (Me Either) (Je t'aime moi non plus) - Cat Power & Karen Elson - I Love You (Me Either) (Je t'aime moi non plus).flac"

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.

AutoFLAC

Reply #136 –
Quote from: nitro322 on
Quote from: Nakkis on
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.

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

Quote from: Nakkis on
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)

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.


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.

Quote
Track   Ripping Status      [Disc ID: 002924c2-2611c814]

1   Accurately Ripped    (confidence 20)    [6d208396]
2   Accurately Ripped    (confidence 25)    [99486416]
3   Accurately Ripped    (confidence 25)    [d7377607]
4   Accurately Ripped    (confidence 20)    [eea74649]
5   Accurately Ripped    (confidence 20)    [ec1f7a0d]
6   Accurately Ripped    (confidence 20)    [047ab160]
7   Accurately Ripped    (confidence 20)    [f8047d8c]
8   Accurately Ripped    (confidence 20)    [ae805f39]
9   Accurately Ripped    (confidence 20)    [cb2cb562]
10   Accurately Ripped    (confidence 25)    [0869727d]
11   Accurately Ripped    (confidence 25)    [2dff5d9a]
12   Accurately Ripped    (confidence 25)    [945d5a50]
13   Accurately Ripped    (confidence 25)    [d84fcc02]
14   Accurately Ripped    (confidence 25)    [7594d90b]
15   Accurately Ripped    (confidence 25)    [4cd2bcec]
16   Accurately Ripped    (confidence 25)    [a3dd7ba0]
17   Accurately Ripped    (confidence 25)    [1fac97fb]
18   Accurately Ripped    (confidence 25)    [7ce70ee0]
19   Accurately Ripped    (confidence 20)    [1be663b6]

_______________________

All Tracks Accurately Ripped.

AutoFLAC

Reply #137 –
Quote from: Nakkis on
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...

AutoFLAC

Reply #138 –
Quote from: bhoar on
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.

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


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

AutoFLAC

Reply #139 –
Quote from: bhoar on
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.

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.

Quote from: bhoar on
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.

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?

Quote from: bhoar on
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.

<SNIP>

What are you thoughts?

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.

Quote from: Nakkis on
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.

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?

Quote from: bhoar on
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...

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?

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

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

Quote from: bhoar on
Thoughts?

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.

AutoFLAC

Reply #140 –
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.

AutoFLAC

Reply #141 –
Quote from: nitro322 on
Quote from: bhoar on
In Track mode:  Burst rip the disc...

Is this really typical user behavior?

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?

AutoFLAC

Reply #142 –
Quote
Quote
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.

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.


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.

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

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?


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.

Quote
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?


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.

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


Thanks.

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


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?


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.

Quote
Quote
Thoughts?

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.


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

AutoFLAC

Reply #143 –
Posted about an old issue. Never mind.  Thanks for all of your effort!


Quote from: nitro322 on
That looks right.  Sigh.

I'm out of ideas at this point.  Everything seems like it should be working fine.  I don't know why your FLACs aren't being converted.  The fact that I can't duplicate the problem on my system makes it especially difficult.

The next step would probably involve a special debugging build of AutoFLAC to print out some additional information of what's happening when.  Stuff like echoing file names, directory paths, etc.  However, I can't commit to working on that at this time.  Maybe in the next week or two.

Alternatively, since AutoFLAC is open source, you could try doing a little trhoubleshooting yourself.  Have you ever done any coding before?  If so, download the AutoFLAC source code and binary archives and try playing around with it, see what you can find out.  Your problem's likely occuring between lines 133-146 or 176-179 (I would guess the latter).

Otherwise, I'll look into this some more as time permits.

AutoFLAC

Reply #144 –
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

AutoFLAC

Reply #145 –
Quote from: nitro322 on
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.
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.

AutoFLAC

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

-brendan

AutoFLAC

Reply #147 –
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.

AutoFLAC

Reply #148 –
Quote from: nitro322 on
Quote from: RolloTomasi on
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"

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

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.


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


Quote from: nitro322 on
Quote from: RolloTomasi on
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.

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?


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.



Quote from: nitro322 on
Quote from: RolloTomasi on
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.

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?


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.

Quote from: nitro322 on
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?


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.

AutoFLAC

Reply #149 –
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?