Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[matt00]

OK,
I am going to rip my cd collection. All 436 cd's in Flac and I want the best sound quality possible. Is
There a difference if I use JRiver 15 set at "5" for Flac quality and in secure mode? Or should I use Exact Audio Copy? Or is there something else? 
I only want to do this once so please help me make the right decision.

Thanks, any info would be greatly appreciated.
 

My equipment is Krell amp, Martin Logan Vantage speakers, PS audio Dac, All Audioqest cable, and a Yamaha cd player.

[sunfire7]

flac is lossless in whatever compression number you rip, settings 0 to 8 all have the same quality, what changes is the final size and the time to encode it.  If you rip with MC, be sure you have set copy mode to "secure". 

If you ask me I would rip with EAC if I need the log for posting or whatever, otherwise i would use MC 15 in secure mode, flac -8

[JimH]

There is no reason to use EAC and no reason to use other than MC's FLAC default settings.  Space savings of other modes are trivial. 

[Vincent Kars]

Ripping and ripping is two.
1 – a bit perfect copy of the content of the CD
EAC has a big reputation but dbPoweramp is catching up.
I do think the sentiment to day on audiophile forwards is dbPoweramp.
Easier to configure and faster than EAC.
Both support AccurateRip.
The results of your rip are compared with the results of others.
However I do think that most media players today including MC15 (when set to ‘secure’) can make a bit perfect rip.

If you want to sure:
- rip a couple of tracks using a damaged CD
- do so using MC15, dbPoweramp, EAC
- load the tracks in an audio editor, time align  and subtract them
If the result is not 100% zero’s there is a difference between them.
I would be surprised, as this type of experiment has been done by many, if you would find any difference at all

2-tagging
Adding meta information and art work to the songs.
I’ am afraid this one of the very few weak spots of J River
Its database is small: http://yabb.jriver.com/interact/index.php?topic=58368.0
If you hit troubles (CD’s not found in the database) you might consider a ripper with better tagging support like dbPoweramp

[Von]

There is no reason to use EAC 

One reason might be that EAC can be configured to use offset correction, a feature which MC does not offer. Proper offset correction means that you and other users will get the exact same file when ripping the same disc/track, provided you both get an error free rip. Because the offset of different drives often vary, the same track ripped with MC 15 will likely be different, if you do a bit compare or hash sum check of the files.

Bear in mind that we are speaking of what will normally be a few miliseconds of silence missing from a track. This will instead be found at the end of the previous track or the beginning of the following track. Apart from this, however, the audio data will be identical.

The significance of this is sometimes debated. I for one would appreciate it if this feature was added in MC, and am still hoping. 

[JimH]

One reason might be that EAC can be configured to use offset correction, a feature which MC does not offer.

I'm sorry, but we've considered this and don't think it's significant for modern drives.

[flac.rules]

I'm sorry, but we've considered this and don't think it's significant for modern drives.

I dont get how "modern drives" have anythong to do with offset correction, do you mean that there is no read offset on "modern drives"?

[Audio Only]

OK,
I am going to rip my cd collection. All 436 cd's in Flac and I want the best sound quality possible....
I only want to do this once .....Thanks, any info would be greatly appreciated.
 

Since you want the best sound quality possible, do not rip compressed. I and others hear a difference.
Rip'em to wav

Search the forum for coolhighend's posts, he believes the same.

Hard drive space is cheap.

[Matt]

Since you want the best sound quality possible, do not rip compressed. I and others hear a difference.
Rip'em to wav

It's good that you like WAV, but it's not good to spread myths.

Lossless compression delivers the same bits to the soundcard as WAV.  The same bits produce the same sound.

[Audio Only]

It's good that you like WAV, but it's not good to spread myths.

Lossless compression delivers the same bits to the soundcard as WAV.  The same bits produce the same sound.

and MC 15 delivers the same bits to the sound card as Foobar.

Gosh, MC15 sounds different from foobar to me.

[Audio Only]

....snipped...We are building Audio Media Computers for the most exigent clients regarding audio quality. Our products are monitored with the most sophisticated equipment. Please understand that they do not accept any kind of compression.

I do not really want to discuss further the differences of lossless audio compressions. But I really would like to use MC, it is a wonderful product.

Instead, I give you another example of sound alteration that cannot be. Do you know that most of our clients are rejecting MC using the ASIO plugin for playout with the hardware we use (Lynx AES16). The sound is simply inferior to another media product that uses another plugin. ASIO is bittransparent, there can't be a differnce but there is on, a huge one. And did you know that your WASAPI is simply gorgeous and that there is a huge difference to your ASIO plugin. WASAPI is bittransparent as well there can't be any differences, or can there be... give yourself a try.

There are others out there that believe that are audible differences in various “bittransparent” forms. Some of them believe that MC when setup properly sounds noticeably better than several other “bittransparent” programs.

Of course, it may just be a myth that MC sounds better,

[Matt]

and MC 15 delivers the same bits to the sound card as Foobar.

Gosh, MC15 sounds different from foobar to me.

I don't have anything bad to say about Foobar.  But that comparison is more complicated.  You have to consider how you talk to the soundcard (ASIO, WASAPI, etc.), how you do bitdepth conversion, how you handle volume, how DSPs are managed, etc.

The only job of a lossless decoder is to output the same bits as the WAV file, which APE and FLAC do perfectly (and in fact, at least with APE, with more reliability than WAV as discussed here).

[sunfire7]

Since you want the best sound quality possible, do not rip compressed. I and others hear a difference.
Rip'em to wav

Try to encode a tagless wav to flac (or another lossless format), and then convert the flac to wav, and check it with a bit compare program, bit to bit is the same, so if you play a wav file and a flac in MC its sounds the same.  I believe that there is a difference between programs, because of what matt says, but as MC use the highest quality process for every task, you are safe with lossless + MC + WASAPI  .

[Vincent Kars]

There are a lot of post on all kind of audio forums reporting audible differences between compressed and uncompressed formats like FLAC and WAV
Likewise a lot of testing has been done.
A nice one: play the same track in WAV and in FLAC and record the SPDIF out.
This is probably the best testing possible because this is what actually is send to the DAC.
Like all other test comparing the bits, this test yielded zero differences on bit level.
No surprise as lossless is lossless.

An often overlooked aspect of PCM audio is the time (sample rate)
Not only should the DAC receive the right bits, they must also arrive at the right time.
Small variations in the time step can become audible, this is known as jitter.

An explanation why bit identical files can sound different is that uncompressing a file does requires more CPU. This extra system load disturbs the clock of the sound card in some way, might be RFI, ripple on the power rails, etc.
If this is true, the implication is that sound quality fluctuates with system load.
I do think this points to a problem with the system, especially the sound card.

You can find many reports on testing bit perfect output. Unfortunately, you won’t find many reports testing the jitter. Simply because this requires gear able to measure Pico seconds and this type of gear is very expensive.

By design PCM audio is a sample (the bits) and a time step (sample rate).
Any explanation focusing on the bits only leaves the other half of PCM (the timing) out of the equation.

[flac.rules]

There is little to no evidence (as far as i have seen), that jitter levels that are within reason (that is, you can obtain them cheap in almost all systems) are antthing close to audible. Do you have any data that can tell me otherwise?

As far as perfection goes, no read offset correction will actuall cause non-bitperfect files in a way. (you might loose som bits at the beginning or end, but as a whole, all bits are intact, however track-changes are at a very sligthly wrong position). Not that this non-perfection will be audible though.

[jmone]

I love these discussions!  Flac, APE, WAV, WMA Lossless...ripping methods...

I'd suggest your DAC and more importantly speakers are far more significant considerations than lossless formats for listening quality.

That said, I try to output all my audio (from video and audio) from lossless sources (WMA, FLAC, WAV, PCM, DTS/DD HD) to PCM on my HTPC using WASAPI via HDMI to a Yami V2700 to Axiom speakers.

Sounds great on my sub golden ears

Thanks
Nathan

[jmone]

...so pick your lossless CODEC based on compatibility of your playback devices, and the ripper on what Meta Data / Cover Art support is best...and enjoy the music!

[flac.rules]

I love these discussions!  Flac, APE, WAV, WMA Lossless...ripping methods...

I'd suggest your DAC and more importantly speakers are far more significant considerations than lossless formats for listening quality.

That said, I try to output all my audio (from video and audio) from lossless sources (WMA, FLAC, WAV, PCM, DTS/DD HD) to PCM on my HTPC using WASAPI via HDMI to a Yami V2700 to Axiom speakers.

Sounds great on my sub golden ears

Thanks
Nathan

It is quite possible to be interested in codec-quality and at the same time be interested in DAC-quality and speaker quality, and even enjoying music on top of that. However it is true that people quite often claim huge differences in things that might not make much of a difference at all (personally, i think it looks like DACs are in that category too), spakers and the room is much mor important than most other considerations (not counting filters)

[Alex B]

- There is no "correct offset" in the Red Book Audio CD standard. The offset is allowed to vary slightly in the manufacturing process (different manufacturing plants may produce Audio CDs with different offsets from the same source material) and in the reader device design. Also standalone Audio CD players have varied offsets. That has newer been an issue because the effect is inaudible.

A read offset correction setting is only useful when a software process is used for comparing files that were ripped with various different readers. MC's secure ripping system doesn't do that. It uses rereading.


- Lossless is lossless. Wave/AIFF and any lossless codec provide unaltered quality. If that doesn't happen then something is broken and should be fixed.

Decoding a usual lossless format during playback is a very light task. Actually, reading the bigger Wave or AIFF files from the disk or network might in some circumstances consume more computing resources than reading and decompressing the smaller lossless files. Anything else that you might do with your PC may cause higher CPU usage spikes than a steady lossless decompression process. In addition, also the uncompressed Wave and AIFF files need to be processed and unpacked to the raw PCM format before the stream can be forwarded (though this is a very simple process).

[Vincent Kars]

There is little to no evidence (as far as i have seen), that jitter levels that are within reason (that is, you can obtain them cheap in almost all systems) are antthing close to audible. Do you have any data that can tell me otherwise?

No, not really.
What I have found on the Internet most of all gives me the impression that the audible threshold of jitter is not  well established .
Maybe the AES has more but I have no access to their library.
What I have found up to now :

In 1974 the BBC research department concluded:
For jitter having a random, white noise, spectrum extending from 30 Hz to 16 kHz, it is estimated that impairment on critical programme would be perceptible to less than 5% of listeners provided the jitter amplitude is no more than 50 ns r.m.s.
Source: BBC

Ashihara (2005) did an experiment indicating that random jitter is not audible below the 250 ns
 
Adams (1994) states that jitter threshold is dependent on the combination of components used in the DAC and concludes that phase jitter has to be as low 20 ps – 1 ns to obtain signals of 16 bit quality.
 
Ivar Løkken, 2005 citing: Dunn, J.: “Jitter: Specification and Assessment in Digital Audio Equipment”,
AES Convention Paper 3361, October 1992.
We can see that the audibility threshold decreases from 500ns at low frequencies to as
little as 20ps at 20kHz. Especially when using formats or converters with high sample-rate this will be a major issue.

The digital equivalent of flutter is periodic jitter, which is caused by instabilities in the sample clock of the converter (Rumsey & Watkinson 1995). The sensitivity of the converter to periodic jitter depends on the design of the converter. Periodic jitter produces modulation noise. Practical research by Benjamin and Gannon involving listening tests found that the lowest level of jitter to be audible on test signals was 10 ns (rms). With music, no listeners in the tests found jitter audible at levels lower than 20 ns (Dunn 2003:34).
Source: http://en.wikipedia.org/wiki/Analog_sound_vs._digital_sound


So we can choose,
If we believe Asihara, , almost all DAC’s will qualify.
If we believe Benjamin and Gannon, al lot won’t
If Dunn is right, very few will.

A bit more details: http://thewelltemperedcomputer.com/KB/BitPerfectJitter.htm

[Frobozz]

It is possible to make ripping a CD as complicated as you want to make it.  If you ask 5 computer audiophiles how to rip a CD you'll get 10 different answers and none of them will be direct or simple.

The good news is that there is no audio quality difference between different ripping programs.  One ripper doesn't give audio quality differences like "this ripper gives the music a better sense of air and stronger bass".  They're all the same.  What is different is in how they handle errors and glitches.  Glitches due to scratched CDs can cause pops and clicks in the audio.  Ripping programs that do error correction generally do fine for most CDs.  Media Center does error correction if configured for "Secure mode" ripping.  It will do just fine.  If you have a particularly scratched CD you might want to compare against EAC just as a sanity check.

I've compared rips done with Media Center to EAC and the rips are the same other than the initial offset of a few samples.  The rips are effectively the same.

So use Media Center to rip.  Set the ripper to Secure mode.  Rip to a lossless format like FLAC.  Use whatever compression level you want for FLAC.  The compression level makes no difference to audio quality.  The compression level just affects the file size and how much computer time they take to compress.

Now some caveats.

If you have classical CDs or Japanese imports or first edition CDs that came from Japanese pressing plants then you might have some CDs that have pre-emphasis.  I wrote a guide on ripping CDs that have pre-emphasis.  Be thankful if you don't have to deal with that.

If you are ripping 500+ CDs you might want to consider buying and using dBpoweramp for the bulk of the ripping project.  dBpoweramp gets meta-data from multiple sources and generally has better or more consistent tagging info.  It also depends on what kinds of music you have.  If it's jazz and classical and eclectic stuff then dBpoweramp will be more likely to have the info than other rippers.  If it's common rock and popular stuff then EAC or Media Center will probably have the track info.  Depends.  YMMV.  But if you're finding that a lot of your CDs aren't in the database then using dBpoweramp could save you a lot of time.  Having to manually enter track info for hundreds of CDs is very time consuming.

[mojave]

Speaking of the audibility of jitter, I thought I'd throw a couple of interesting articles out here. The first is a magazine article that essentially is giving an overview of the technical paper in the second link.

Measuring what we value or valuing what we measure? from 2009

Audibility of temporal smearing and time misalignment of acoustic signals from 2007

[Alex B]

What is different is in how they handle errors and glitches.  Glitches due to scratched CDs can cause pops and clicks in the audio.  Ripping programs that do error correction generally do fine for most CDs. ...

Regarding "error correction", not all programs do anything that can be considered as "secure ripping" when a possibly available error correction setting is enabled. AFAIK, on Windows only Media Center/Media Jukebox, foobar2000, dBpoweramp, Plextools (works only with Plextor drives) and the recently introduced CUERipper have a reread capable secure mode.

For instance, I don't think Apple and MS have fully explained the error correction settings in iTunes and WMP, but certainly they don't try to rerip possible bad sectors until a repeatable result is got (-- in a reasonable time. If I recall correctly MC tries to reread up to 16 times.)

[Alex B]

I did some searching. I think the error correction setting in iTunes and WMP does the same that JohnT explained almost seven years ago:

I wouldn't bother using "Digital error correcting mode", although if you find a bug with it let me know. That mode is only to correct "jitter" which usually isn't a problem with drives with the "accurate stream" feature which most drives made in the last 5 years have.

The important mode is "Digital secure" which competes with EAC's secure mode for getting error free rips.

(- "Digital error correction" is not anymore an available mode in MC. "Digital secure" is now called simply "Secure".
 - The mentioned "drive jitter" has nothing to do with the jitter that can happen when digital audio signal is processed in the DA converter during playback.)


That old "Comparing MC to other rippers - my test results" thread is a good read. (http://yabb.jriver.com/interact/index.php?topic=15912)

[flac.rules]

Thanks for some interesting links about jitter to Vincent and mojave, I have seen a few of the papers before, but not all. (even though i actually did a search on the topic a little while ago, myabe my searcing muscle isn't so strong. Always interesting to have get new sources of information (you don't happen to have any papers on the audibility of different transistor-amplifiers too? I was recently on the hunt for some info about that)

[flac.rules]

- There is no "correct offset" in the Red Book Audio CD standard. The offset is allowed to vary slightly in the manufacturing process (different manufacturing plants may produce Audio CDs with different offsets from the same source material) and in the reader device design. Also standalone Audio CD players have varied offsets. That has newer been an issue because the effect is inaudible.

A read offset correction setting is only useful when a software process is used for comparing files that were ripped with various different readers. MC's secure ripping system doesn't do that. It uses rereading.

But the offset will also cause you to loose a few samples at the beginning of the first song, or end at the last song if you have a more or less normal reader. But as you say, the effect is inaudible, and largely irrelevant, but it can be argued that its not bit-perfect.

[Alex B]

The Audio CDs have varied offsets (as I explained, even different pressings of the same CD may have different offsets). The drives have varied offsets. There is no correct offset.

Also a set offset correction may cut same samples from the beginning of the first track or from the end of the last track. Only some drives can overread into lead-in/out data.

In a sanely mastered Audio CD the very first and very last samples are silent or contain only inaudible steady background noise because the offset variation is a known factor.

The only "standard" was introduced by the EAC developer for comparison purposes:
http://yabb.jriver.com/interact/index.php?topic=57693.msg391480;topicseen#msg391480

[flac.rules]

The Audio CDs have varied offsets (as I explained, even different pressings of the same CD may have different offsets). The drives have varied offsets. There is no correct offset.

Also a set offset correction may cut same samples from the beginning of the first track or from the end of the last track. Only some drives can overread into lead-in/out data.

In a sanely mastered Audio CD the very first and very last samples are silent or contain only inaudible steady background noise because the offset variation is a known factor.

The only "standard" was introduced by the EAC developer for comparison purposes:
http://yabb.jriver.com/interact/index.php?topic=57693.msg391480;topicseen#msg391480

I don't think we disagree in any way, as we both have said, the offset is inaudible, and you can loose some samples at the being or the end of the CD. The last factor can arguably be said to cause the ripping to be non-bitperfect. Even though it has no practical relevance.

[Alex B]

The read "bits" are always perfect unless a read error occured. Read offset doesn't affect that.

For evaluating bit perfectness that includes also the offset you would need to compare the ripped tracks with the original master tracks (i.e. with the source audio data that was used in the CD manufacturing process).

[flac.rules]

The read "bits" are always perfect unless a read error occured. Read offset doesn't affect that.

For evaluating bit perfectness that includes also the offset you would need to compare the ripped tracks with the original master tracks (i.e. with the source audio data that was used in the CD manufacturing process).

Yeah, the read bits are perfect, but not all bits are read. Because the offset can cause missing a few samples at the beginning or the end.

[Frobozz]

J River has a good ripper.  It works.  It works well.  You can use it with confidence in secure mode.  If there are problems detected during the rip it will note the problem sections in a log file.  You aren't left wondering after the rip if there are errors.  And ripping within Media Center can make for a more convenient workflow than ripping with a third party program.

The offset correction is only an issue for perfectionists who want to be able to make an exact audio copy of the CD and repeated exact audio copies.  It's not an important feature for normal use where you're ripping tracks to your listening library.  Offset correction could be desirable if you're ripping a CUE for archival purposes.  But how often to you do that and if you do have that need just use EAC for that rip.

Rather than fuss over offsets I'd rather have the J River ripper alert if the CD has pre-emphasis and even better to have an option to automatically correct for pre-emphasis during the rip.  That would be cool.

[JimH]

Rather than fuss over offsets I'd rather have the J River ripper alert if the CD has pre-emphasis and even better to have an option to automatically correct for pre-emphasis during the rip.  That would be cool.

If you will send us a disk, we will take a look.  No promises.  I'm jimh at jriver.