Throw darts at this... WMA-LL, Re-ripping, "best practices"

[MarkDee]

Hello all

I believe in giving back.

I'm testing a path I might walk in the future weeks & months.

If the method survives your positive critique, I WILL write a summation for new people which details ALL the settings, ALL the variables, and gives credit to all the people who have come before me on the topic I'm about to discuss.

Thanks already to those of you who have helped me come to certain conclusions...

BACKGROUND
I have 1000's of CD albums - nothing like a few of you (!)

I have previously ripped exclusively to WAVE - not wanting to miss a byte (!)

I have multiple PCs from which I work -- all QuadCore/Vista64 networked over GigabitEthernet.

I am a paying subscriber to all DbPowerAmp Products.

I use MediaCenter (currently testing beta V.13) for file management and SlimDevice SqueezeBoxes for in-home distribution.

[Personal] I'm retired with 25 years of IT experience.

SITUATION
(tell me this doesn't sound familiar...) I want to perform the "FINAL" rip session of the current discs so that I NEVER have to do this again.

PROPOSED SOLUTION
-Utilize "Multi-Encoder"
-Force Dual use of WMA (9.2 LossLess) encoding to separate locations (one for immediate consumption -- the other on the "Never to be touched" drive for backup)
- Use MC13 for the short term integration of newly ripped WMA's, recently ripped FLAC's [had some issues with FLAC - that's why I'm going with WMA], previously ripped WAVES [as I implied there's thousands and thousands of songs in that format], and all other [Misc MP3's gathered legally from various sources].

RATIONALE
Although I've decried in earlier threads (http://forum.dbpoweramp.com/showthread.php?t=17851) my need for much tag information, THIS PROGRAM's INTEGRATION OF MULTIPLE METADATA SOURCES JUST ROCKS. I want a format that will capture as much data as possible (SINCE YOU'VE MADE IT SO EASY).

Although WMA consistently gets "beat up" for being proprietary, I've built a lot of proprietary products in my lifetime as well. That doesn't necessarily scare me since I figure MicroSoft's presence is so large it nearly guarantees that someone will always be working to "provide solutions" that MicroSoft itself fails to deliver.

Every program I'm interested at this point -- whole list to follow in the summary document... -- supports WMA LossLess 9.2.

Thanks again to dbPA, my file structure means that the minimum information I consider critical to my own collection is secure: AlbumArtist, Artist, Album, Year, Track, Title.

FEEDBACK
My Rips are coming back "secure" with "Verify" enabled.
Please tell me --

- What Am I Missing ?

/ THANKS IN ADVANCE
/ MarkDee

[bhoar]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

PROPOSED SOLUTION
-Utilize "Multi-Encoder"
-Force Dual use of WMA (9.2 LossLess) encoding to separate locations (one for immediate consumption -- the other on the "Never to be touched" drive for backup)

This part of your solution seems, to me, to create a significant loss of speed during the rip process. If you're encoding with WMA Lossless twice you're taxing your CPU twice. Depending on the number of drives, cores, passes, etc., this might slow down your workflow.

Instead, I'd probably end each session with a copy of the current session's output to the backup drive.

Now, if that's less convenient than the wait that double conversion to the same codec gives you, then...that's fine.

I wonder how you're handling two different paths? Are you ripping the CD twice, once with one profile, once with another? If so, that will definitely double the ripping time (significantly worse than the delay using multi-encoder).

-brendan

[Teknojnky]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

isn't there a copy/re-org dsp which can copy the ripped files to a new loc (your backup) after encoding? thus encoding only once and still getting 2 copies.

you should also be able to use 'run external' dsp to run a batch file to copy to your backup after encoding.

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

If you're encoding with WMA Lossless twice you're taxing your CPU twice. Depending on the number of drives, cores, passes, etc., this might slow down your workflow.

QuadProcessors/Vista64/8GbRAM -- /not too concerned...

I wonder how you're handling two different paths? Are you ripping the CD twice, once with one profile, once with another? If so, that will definitely double the ripping time (significantly worse than the delay using multi-encoder).

ONE PROFILE - two paths simply to create an "untouchable" archive...

BRENDAN --

Thanks for your input.

Given your 5star status, the input is greatly appreciated.

My own efforts to find 'answers' here simply replicates the experience of many, many people before me. THIS IS A GREAT PROGRAM but it is hard to find answers for the new person who is simply trying to "get on board" with the crew who is already "in the know."

/ MarkDee

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

isn't there a copy/re-org dsp which can copy the ripped files to a new loc (your backup) after encoding? thus encoding only once and still getting 2 copies.

you should also be able to use 'run external' dsp to run a batch file to copy to your backup after encoding.

Obviously going to look into this...

Got different results from the WMA encoder when I asked for "verification" on one and not the other... [whole other topic here...]

If I could RIP confidently (with verification) and then simply copy the files (automatically through the program) then that would be great (!)

As mentioned previously, I'm retired although I work full time raising money for my local hospital (here in Ontario) so I'm at the computer all day and if I simply rip 10 or 12 discs a day ACCURATELY, that's fine (!)

/ MarkDee

[Spoon]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

>SlimDevice SqueezeBoxes

FLAC is the best format for these devices as WMA-L is uncompressed before streaming (if I remember correctly).

All Lossless codecs have a verify option, this ensures there are no Codec errors or Hard Disk errors when encoding.

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

>SlimDevice SqueezeBoxes

FLAC is the best format for these devices as WMA-L is uncompressed before streaming (if I remember correctly).

All Lossless codecs have a verify option, this ensures there are no Codec errors or Hard Disk errors when encoding.

Although (you're correct in remembering) SqueezeCenter transcodes before streaming, the only feature I "lose" is the ability to fast forward or reverse within a track. This is NOT a problem for ME.

I don't work for SlimDevices or Logitech (as mentioned previously, am retired) but I love their product. To test every aspect of my goals before kicking off another run at "ripping everything over again" I booted up the SB which is integrated with my HomeTheatre Stereo (there's a few more around the house).

Automatically updates firmware. Polite messages (something may take a minute or two -- that sort of thing). BOOM. All the music is available, even the fact that FF or Reverse is not possible with this format is communicated via the screen.

My home network is entirely wired -- Gigabit ethernet.

Since the point of this thread was to hunt down the "red flags" I'll say at this point:

I'm still not seeing a reason not to use WMA LL.

/ MarkDee

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

isn't there a copy/re-org dsp which can copy the ripped files to a new loc (your backup) after encoding? thus encoding only once and still getting 2 copies.

Obviously going to look into this...

If I could RIP confidently (with verification) and then simply copy the files (automatically through the program) then that would be great (!)

Have looked and cannot find such a (COPY/RE-ORG) DSP...

[apb1]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

Your set up sounds similar to mine. I use:

--EAC to rip music to WAV (including CUE file generation for archival purposes)
--MediaMonkey to manage the music library and tags (it has decent tag grabbing from amazon facilities...I'd rather us dpPA cd ripper for tag gathering but I've been having problems with the files it generates and MM). MediaMonkey is really one of the best music managers I've ever used and highly recommend it.
--dbPowerAmp batch converter to convert WAV files to a variety of formats.
--SqueezeCenter music server for playback throughout the house.
--EFChecksum Manager to generate/test checksums for all my music files/cover art/cue files and backups (I've had several instances where drives and/or motherboards where unreliable and would randomly flip bits)

I basically keep two backups on external disks -- one off site. There is no way in the world I'd want to risk losing the effort I put into ripping the library. I recently had my home computer stolen, and this really hit home.

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

Your set up sounds similar to mine. I use:

--EAC to rip music to WAV (including CUE file generation for archival purposes)
--MediaMonkey to manage the music library and tags (it has decent tag grabbing from amazon facilities...I'd rather us dpPA cd ripper for tag gathering but I've been having problems with the files it generates and MM). MediaMonkey is really one of the best music managers I've ever used and highly recommend it.
--dbPowerAmp batch converter to convert WAV files to a variety of formats.
--SqueezeCenter music server for playback throughout the house.
--EFChecksum Manager to generate/test checksums for all my music files/cover art/cue files and backups (I've had several instances where drives and/or motherboards where unreliable and would randomly flip bits)

I basically keep two backups on external disks -- one off site. There is no way in the world I'd want to risk losing the effort I put into ripping the library. I recently had my home computer stolen, and this really hit home.

We do share some common ground.

Have used EAC in the past -- found dbpAmp far superior.

Bought into the MM craze - don't know how else to describe it... would gladly give my license to anyone who wants it.

SqueezeCenter Rocks (!)

Never heard of EFChecksum Manager - why would I need that with dbpAmp's verification ?

Have you ever looked at MediaCenter?

[apb1]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

We do share some common ground.

Have used EAC in the past -- found dbpAmp far superior.

If dbpAmp generated CUE files (and I can figure out some issues with WAVE files) I would gladly switch to it. Lack of CUE file support rules it out for me.

Bought into the MM craze - don't know how else to describe it... would gladly give my license to anyone who wants it.

I love the transparency of MM but it definitely has a few issues with tags -- but I've figured out workarounds for most them. Nested playlist support is another big win here.

SqueezeCenter Rocks (!)

I totally love my Transporter! SqueezeCenter is great, although it still has some fairly annoying issues with unicode characters under Vista.

Never heard of EFChecksum Manager - why would I need that with dbpAmp's verification ?

I like it because it adds checksums for all the files including cue sheets, jpegs, etc.. Also, trivially easy to verify entire libraries. I basically use the same program to verify all of my backups including photo library and personal files. I think you get a lot of the benefit with built-in checksums though. It's not a replacement for AccurateRip. It just tells you if your files should become corrupt.

Have you ever looked at MediaCenter

Not really, can you give a link for it? Looking up media center gives tons of links to MS junk.

[MarkDee]

Re: Throw darts at this... WMA-LL, Re-ripping, "best practices"

APB1 /

Thanks for your message... Just you follow up:

You can find MediaCenter at http://www.jrmediacenter.com/

There's also a pretty active forum site at

http://yabb.jriver.com/interact/

in case you want to do some background reading...