Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Systems Ripping Software

Thanks for the comments - I guess I need to move over to dBpoweramp!

Incidentally, one incidental problem which I now realised was caused by the invalid files was that it actually affected the actual HDD which I was using to mirror the music files. It would repeatedly lose 'connection' with Windows and there would be error messages appearing. After I cleared out all the invalid files the problems stopped!

dBpoweramp is so much easier and quicker! Still time consuming converting all my CD's. I am about half done but already loving the ability to access music that before was out of site and mind.

I already ready ripped my CD's using FLAC (I'm using dBpoweramp), but I forgot to add the HDCD setting. If I use the batch ripping option where I add HDCD, will it compress my songs further when set to FLAC. I noticed there is no way to turn this option off during the batch ripping.

I want to make sure that I am not compressing my songs further when using the batch ripper to add HDCD. Will this be the same if I have files ripped in Apple Lossless and they get converted to FLAC with HDCD?

In addition to that, I have some music that is already in MP3 (192kbps), is there any reason I should convert these to FLAC?

I know some of this may seem like dumb questions, but I am somewhat new to the whole "ripping thing" since I just got my SONOS.

Thanks!

I am new to this too so looking forward to the answers. Although I would just leave the MP3's as they are.

HDCD only operates on lossless.

It will unpack the files to lossless WAV, check for HDCD if present output 24bit WAV else output original lossless WAV, then dBpoweramp will reencode them to what ever format you desire (FLAC at default compression typically).

If you were to apply a "post processing step" on a lossy format (MP3) that would be bad. Because you would lose data by decompressing and recompressing to a lossy format a 2nd time. With lossless you don't lose anything. HDCD will not be detected in an MP3 format but you would not want it to decode and encode to MP3 or FLAC.

The problem with doing the whole library is dBpoweramp might name the file slightly different or organize folder and location different according to your settings. Tags will be fine. To minimize this you can to a dry run of HDCD post processing (i.e. no output).

Then look at the log to see which albums it found. It generally won't find that many so it's managable. Then I go back and manually to do a real processing job with output to a new tree for ONLY the HDCD albums it found and you manually select (this takes 5 minutes to setup). Then I have a tree of originals and a small tree of HDCD processed only. Then you can manipulate the tree as you see fit (i.e. you could replace orginal albums or what ever you like, you can set dBpoweramp to replace them too). Since I have multiple applications I like having both around. It's important to have the reference version for flexibility around this. You really have to use it a bit to understand how flexible and powerful it is.

If you have files already in MP3, leave them as MP3. Converting to FLAC buys you nothing. And if you decide to recompress say for a portable player you will lose information by recompressing vs copying the orginal MP3.

By the way the exact same thing applies to photography. Always take pictures in RAW format and keep RAW (if you can) as your master copy. As soon as it's a JPeg and you do any touch up (post processing) you lose quality every time you decode and re-encode in a lossy format (jpg is lossy RAW is not).

Thanks George. Awesome information. That helps a lot.

I do photography on the side and I totally agree. I shoot everything in RAW.

Thanks again.

Nick

George,

Thanks for the photography analogy. Now I understand a bit more on 2 hobbies.

I have been in the process of ripping my entire collection (ripping in FLAC) using dBpoweramp and I noticed on many occasions certain songs, will have to be re-rip "frames." I pretty sure I understand what is going on, however, can someone explain frames better? Are frames individual bits of song data that are somehow "messed up" from the original song.

What I don't understand is I can take a CD that seems to be in pristine condition (i.e., no scratches or damaging marks) and it will take forever to rip even one song. It took over an hour to rip two songs (they both had about 550 frames each to re-ripped). It just seems a little weird that there could be that many errors.

If I notice a song has a lot of frames, I will cancel the rip and then use iTunes to rip the songs using Apple Lossless with error correction set to "on." iTunes rips the same song in a couple of minutes. So why can iTunes do it a lot less time than dBpoweramp? And what does "Secure" ripping mean.

Honestly, I can't tell a difference between a song that had many frames ripped with dBpoweramp and that same song being ripped in Apple Lossless with error correction on.

Here are my settings on dBpoweramp:

FLAC
Compression Level - 8
Ripping Method - Secure

Lastly, is there any sound quality differences between the different compression levels (e.g., 8 vs. 5 vs. 0, etc). It seems for most of my CDs, the difference in total file size might be anywhere from 25MB - 50MB range between Level 8 (Best) and Level 0 (Fast). After thinking about this, It seems I should be ripping everything at Level 0. Level 0 is still half the size of ripping a CD in .WAV.

Anyhow, sorry for the long post. I just want to make sure I understand ripping as best as I can. And while dBpoweramp's Support site provides some good information, it still seems like there is a lot to learn.

Thanks!

Nick

IIRC FLAC's compression complexity is a lot higher than its decompression (which is generally the way you want it for playing back on dumb devices), and the level is just the amount of computation you want it to take to try and make the file as small as possible while still being 100% bit-perfect. It's like having the equation 1+2+3+2+1=9. 0 is stored as 1+2+3+2+1 and level 8 is stored as just 9 but it took more work to get to that result.

You can analogize frames on a CD to sectors on a disc. It's just a compartment for X number of bits in the track. I believe iTunes just rips the same frames again and compares them. If equal, move on. dBpoweramp appears to go into the real secure mode that EAC has, to ensure it really is getting the right bits. If you don't like this about dBpoweramp you can change the setting to just do Burst rips or you can change the secure settings so that the maximum re-reads is reduced from the default of 34 times.

BTW I just noticed R13.2 is out now, so it might be worth downloading the upgrade

When you do a secure rip with dBpoweramp or eac and it's not found in the accurate rip database. It rereads the disc over and over to get a statistical sampling. iTunes and WMP player depends on hardware error correction which is weak or non existent in many drives. This is why accurate rip is so nice and secure and fast but if it's not in db then you have to do it the old way.

I recently read squeezebox has some issues with high compression flacs. It's not worth going above the default. It takes much longer to compress and you don't gain much savings and it's more work to decode (even though as 506 says most of the work is done the encoding side).

Thanks for the info. This helps a lot.

Nick

I had a number of discs, maybe 20 out of 1500, where dBpa did the "re-rip frames" thing as well. A frame on a CD is a chunk of data that has a computed error checking code associated with it (IIRC, 75 frames/second of music). If dBpa reads a frame, and its computed error code doesn't match the one on the disc, it will keep re-reading the frame until it comes out right.

Sometimes, the frame reading issues were fixed by cleaning my discs. Other times, though, the errors were specific to the drive I was using to rip the disc. My Memorex drive would tend to exhibit these errors on the last track of very full CDs (like 75 minutes or so). I could often cancel the rip of that track, rip it from my LG DVD-ROM drive instead, and it would not need to re-rip frames, or at least far fewer. The LG, on the other hand, would sometimes have issues on the first track.

What's interesting about this is, most ripping software would never even figure out that such read errors had occurred.