Despararate Request - Accurate/Inaccurate Directories

[EliC]

I have been playing with the batch ripper. When doing large batches there is a major problem -weeding out the in-accurate rip discs!! This has to be done manually.

I have requested before the option to either:

1)Rip to a temporary directory and move the rip to an accurate or inaccurate directory after the rip

or

2)Default to 1 directory and move inaccurate rips to a second directory

This is tedious when ripping by hand, but you are there and see the results of each disc. With the batch ripper you have to go back through the results and match them up with the directories, then re-create the directories in a separate innaccurate dir.

PLEASE, PLEASE, PLEASE add this feature! Thank you Spoon for your time.

If others think this would be helpful, LET SPOON KNOW! It will be a low priority if he doesn't think it will be useful to others!

[egd]

Re: Despararate Request - Accurate/Inaccurate Directories

EliC, having now used batch ripper for most of the day yesterday, I have to agree with you - I'd far rather suspect rips get moved to a separate folder than have to trawl through the log files trying to remember which rips contained warnings.

[bhoar]

Re: Despararate Request - Accurate/Inaccurate Directories

As per Eli's request, I've copied my "rip-quality directories" suggestion here from the last post on page #1 of this thread ( http://forum.dbpoweramp.com/showthread.php?t=16311 ). Spoon/LtData, sorry about the double posting, I'll leave it up to you whether to leave both posts or delete one of them. Thanks

...

From the previous (locked) thread, Eli said:

"-Separate accurately ripped and inaccurate directories: When a disc is ripped accurately the files are placed in the normal directory. When one or more tracks on the disc are inaccurate the user would have the option to move all of the disc, or just the inaccurate files to an incomplete or inaccurate directory separate and distinct from the main library. If in the future the disc is repaired or a different copy of the same pressing is ripped and all of the files are ripped accurately dB moves the album over to the accurate directory."

I'd like to see something similar, but perhaps framed in such a way that it is easier for spoon to implement? This would be a general ripper feature, not just limited to the batch ripper.

Really, my ideal process would work something like this...

1. An option can be turned on to sort each CD's output by the quality result of ripping (accurate, secure, insecure/unfinished) vs. a single output path.

e.g. At the end of the cdgrab.exe (ripper) task, it, or a dsp effect, goes through the in-memory record of this CD and decides whether to move the CD's directory from Working to either Secure or Accurate (or not at all).

There are three sister directories defined, perhaps all required to be on one volume (for performance reasons - a move within a volume does not involve reading/writing the entire file) or in one particular sub-tree:

- Working (or Incomplete) directory - all ripping happens here initially and stays here if the rip is either aborted or *any* track is insecure.

- Secure directory - if all tracks were ripped secure but one or more tracks was not in Accuraterip or did not match Accuraterip, the files get moved here.

- Accurate directory - if all tracks were ripped accurately, the files get moved here. That is, this is always the final resting place for known good rips. Perhaps the threshold is adjustable (e.g. requires Accurate (3) or higher).

Spoon may want to implement the setting via a) custom code and a new GUI feature or b) some sort of DSP effect (perhaps the DSP action can check to see if it is running on the final track before acting) or c) a pathname variable (hard to see how that would work). The important part to note is that the final path is only known when the CD has finished (or aborted) ripping, so that needs to be kept in mind in terms of where the appropriate option comes in.

2. An additional add-on would be an option to have the ripper automatically skip completed tracks found in the Working directory. Possibly even only skip accurate or secure tracks found in the working directory.

-brendan

[Teknojnky]

Re: Despararate Request - Accurate/Inaccurate Directories

This could all be solved by a simple naming token:

[status]

where status can be:

- Accurate(#)
- Secure
- Insecure

etc, basically anything that shows up in the 'rip status' column.

With a [status] token any number of naming patterns could be used.

[EliC]

Re: Despararate Request - Accurate/Inaccurate Directories

The problem is you don't know if the rip is accurate until after the rip is done. Plus with the naming token you could have some songs from a disc in one directory and others in a different directory.

[bhoar]

Re: Despararate Request - Accurate/Inaccurate Directories

The problem is you don't know if the rip is accurate until after the rip is done.

Right, that's the key - typically the naming path is used immediately by the ripper as it or the codec/DSP subtasks that it calls are outputing the ripped/compressed/converted music file. Adding a naming token, though mentioned in my comments, would not be a drop-in simple solution because the value wouldn't be set *until the entire disc was finished* and the files were already layed out using the path containing the naming token.

Of course, spoon's code base uses naming tokens, so the change would have to interact with the naming codec code in some way. Hmm.

Plus with the naming token you could have some songs from a disc in one directory and others in a different directory.

Right. I was assuming disc-based placement, not track-based.

I wonder if we can come to a consensus on whether the placement should be track-based or disc-based. I was assuming disc-based because that's how I work with physical media. If I ended up with an irrecoverable track, after several retries, I would just move the rest disc contents manually.

Back to the main topic...

An alternate path scheme that might not interact badly with the naming token...

The paths could also be organized how some coding project are, in that the special case directories live inside the target directory, which could be assumed to be the "Accurate" directory. Then two additional directories "__Insecure CDs" and "__Secure CDs" could live inside the standard target path. Similar to the use of "attic" or ".attic" in software source code storage for temporary storage, archive of old versions, etc....things not part of the final package.

Sorry, perhaps a bit too far into the weeds making assumptions, perhaps. Spoon has the code, he'll know where the pitfalls are and whether there are any graceful ways to add this requested feature.

-brendan

[EliC]

Re: Despararate Request - Accurate/Inaccurate Directories

Plus with the naming token you could have some songs from a disc in one directory and others in a different directory.

I meant this as a bad thing as you would fracture the location of your files. I certainly prefer a disc based approach. I don't know how much more trouble it would be to allow the user to choose if they want disc vs track based sorting.

[Porcus]

Re: Despararate Request - Accurate/Inaccurate Directories

For my own purposes, I have an AutoIT script running which scans the log files. It is quick & dirty in that it does not really pick the working directory, only the most recent directory, but it works for me -- you might want to fiddle a bit back and forth according to whether you want to overwrite. In my setup, I generate a screenshot at the end of each CD; it gets a filename containing e.g. "### INSECURE 11 12 WARN 10" based on the log file.

So what you can do, is
-> at the end of the CD, scan for the most recent .log file
-> from the .log file, decide where (or whether) to move the folder.
-> move the folder.

[EliC]

Re: Despararate Request - Accurate/Inaccurate Directories

I think a lot of people would need to re-create a directory tree. I for example use:

artist/album/## - title

also, the suggestion for an AutoIt script will not work at all for the batch ripper.

[Teknojnky]

Re: Despararate Request - Accurate/Inaccurate Directories

RE status is unknown until after ripped: of course, when ripping the files should have a temp folder/filename that is renamed after final processing. Its not rocket science, if you use the replaygain dps all files are updated after the rip as it is. All that would be needed is to apply a rename/move dsp utilizing the [status] token as the final dsp in the chain.

RE track vs album: this could of course have different implentations, the simplest of which would probly result in separate folders and/or filenames (dependant on the mask you use). Other implementations could look at the overall status of the album and apply the applicable token string to all tracks of the appropriate state of the album.

heck, you could expand the [status] token request to 2 parts;
[trackstatus]
[discstatus]

and there the user would have the choice and flexibility to route the album and/or tracks to the applicable folder/file structure they want.

[EliC]

Re: Despararate Request - Accurate/Inaccurate Directories

Teknojnky, you are correct. I think this would be easily handled in the manner you suggest with a DSP. Hopefully spoon will either create one or open up to DSP creation by 3rd parties.