Hi, I was messing around with RMAA trying to see what are the results of playing an audio CD from the cd drive v/s playing the wav file of those tracks from the harddisk. The results are interesting (atleast to me) and I'd like to get your thoughts on these, especially the differences and get some answers as to what could cause such behaviour. Although i have measured many devices with rmaa I am not sure how to interpret these results and if anyone can share some thoughts, that would be great!


Basically a wav file is played and rmaa records it and spits out the results. What I did was play that wav file off the hdd first and then repeat the test by playing the wav file (burnt to an audio cd) from the cd drive.

I also threw in one more variable. I repeated the same set of tests (cd v/s hdd) with and without the SSRC resampler in foobar. i.e. first using the soundcard's resampler and then using foobar's resampler(assuming the soundcard does not resample the already resampled 48khz stream).

Sound card is Turtle Beach Santa Cruz and the drive is a LiteOn LTR-48246S.


Now lets see what we got. In all images, the white curve is the SoundCard resampler and the green line is the FooBar resampler.
Lets start with the frequency response. Don't pay attention to the sudden rolloff, the Y-axis (db) scale is very small.
First the frequency response with the CD Drive:



=========================================

and then the frequency response with the Hard Drive:





As you can see both are identical, but notice how it ripples after 1Khz whenever the soundcard's resampler is used. With Foobar's resampler its flat.

So what does this ripple indicate ??



Now lets move on to THD. First with the CD Drive:




==========================================

and then with the harddrive:




Notice how in the harddrive chart the spike is sharp and clean and the next harmonic spike is at 2Khz, but in the cd chart it widens up at the bottom and then it bounces on its way to 2Khz. What causes this ? Why is it different ?

Also, see the humps in the chart near 20Khz ? What are these humps ? and why are they different between the soundcard resampler and foobar resampler curves ?


Finally, the IMD charts. For CD Drive:-



===========================================

and for Harddrive:-




Exact same behaviour as the THD charts. The same broad spike and the 20Khz humps. Like I mentioned before I am not sure how to interpret these results. Can anyone share some thoughts on these ?

In the THD charts, I think that the bump at the high end is the noise shaping algorithm which pushes the noise to the enc of the spectrum.

Regarding the differences between CD and hard drive, it might be because of different sampling/display parameters of the results. It would help if you used the same scale on both charts.


Now, let's talk about playing from the CD. How are you doing it? There are 2 possibilities:
*Use the CD reader as a transport, ie reading digital data from it that is latter converted to analog by the sound card
*Use the CD reader as a player, ie using its analog output that is then digitized by the soundcard before beeing converted back to analog by the soundcard.

The ripple in the frequency response indicates that your soundcard uses a low (er) order filter for resampling than foobar2000 does. Notice that it also drops to 0 sooner, i.e. the bandwidth is smaller. In filter design you trade transition bandwidth vs. ripple vs filter order (processing/hardware requirement). Foobar has got the soundcard beat both times, but of course, it can use a heavier resampling algorithm than the card does.

I have measured other cd players also - a pioneer dv-563a, portable discmans, and a bose wave cd-radio too but none of their thd charts have that hump in the end. I would imagine these noise hump should also show up in those cases(?)

The scale was changed on purpose to zoom in on the 1Khz spike to show better its artefacts. Rest assured scale is not the problem.

I am not using the analog out from the cd drive. The soundcard does the conversion. I am also not using spdif from the drive either, just plain old IDE interface.

We can't make any comment without knowing how the measurments were done. RMAA is a software, it does not have RCA inputs. It records what Microsoft Wave mapper input device (set in the control panel) throws at it.
This device is the input of a soundcard.

Is the recording made in loopback mode, with the line output of the soundcard plugged into the line input ? What are the settings of the input mixer ? What are the results of the soundcard recording itself ?
Was the recording made with another soundcard ?
Was it made with the input mixer set on "wave" (digital internal loopback) ?

Thanks. Please do ask such questions as I might have missed providing such information in my original post.

The soundcard's LineIN and LineOUT were used via a short loop cable.
Everyting in the windows mixer is muted/turned off except the WAV output in playback and Line IN in recording, so there will be no internal loopback. The only signal path is the lineout->linein via the loop cable. Playback is done using Foobar and Recording is done using RMAA.
The wav file of the 25-30second test signal that rmaa uses has already been created. When testing I start "recording from an external source" in rmaa first and then start playback of that wav file in foobar. Hope this helps.

Yes ofcourse the same soundcard was used! At this moment I dont have access immediately to post rmaa results of the soundcard itself but like I mentioned its a Turtle Beach Santa Cruz and the results are excellent and perfectly normal. Same as many other rmaa results of this card posted on the internet at various places.

Maybe I could burn the same raw wav file to a data cd and play it from there and see if I get the same results(?)

Yes, test it from a CD-rom, you should get the same results as with the audio CD. In fact, I think that you will get the same result if you play the file from the hard drive while copying the content of a CD-rom on the hard drive.

It seems that your CD-rom drive affects significantly the power supply of the computer, that in turn produce amplitude modulation on the analog output / input of the soundcard, which is visible in your graphs at the bottom of the spikes.

You can even prove that it comes from amplitude modulation (the output gain varying when the power supply is busy) if the soundcard can playback and record DC currents.

Create a wav file with a DC signal. Record it with the CD ROM active, and with the CD ROM inactive.
If indeed it introduces amplitude modulation, you should see in the noise spectrum the apparition of spikes around 83 Hz , 167 Hz, 250 Hz etc when the DC signal is played back, that are not there when the CD rom is inactive, or when the soundcard doesn't play DC.

Edit : the use of a DC signal rules out jitter as cause of the distortion.

PS : the spikes will be at multiples of 83 Hz if the drive spins exactly at the same speed and reads the same part of a CD as when you got the above results.

Using "digital internal loopback" mentioned by pio would be better than cables between line in & out, wouldn't it?

Yes, but it would not measure the global playback performance.

Wow! Having insufficient/non adequate power supply in a computer is something unfortunately usual, but I never thought that soundcards would not be including voltage regulators.

yes and as it stands right now I am afraid what Pio said might turn out to be true in my case...stay tuned...

We ran the same experiment as you in a french forum, and got no problem playing audio from a Plextor 716A using Foobar2000 on two different computers.

French discussion :
http://www.homecinema-fr.com/forum/viewtop...20307#169520015

Gbo has an ESI Waveterminal 192X soundcard and uses Winamp 5.112 to play the CD.
My config is :

Power supply : Tagan TG380-U01
Motherboard: Asus A8N-E
Drive : Plextor 716A

Here is the bottom of the 1 kHz spike of the DHT test of RMAA, in external analog loopback.
Soundcard : the AC97 chipset in the motherboard.


1-From the hard drive (alone)
2-From the hard drive while a DVD is copied on the hard drive (drive)
3-From the hard drive with an audio CD being ripped on the hard drive (drive-audio)
4-From an audio CD played by Foobar2000 (CD-F2000)

Here are the results with the Marian Marc 2 soundcard, external analog loopback :


However, moving the mouse, or dragging a window with the mouse causes audible clicks in the ac97 audio chipset of the motherboard, but nothing at all in the Marc 2 :

AC97 Chipset and Marian Marc 2, idle mouse :


AC97 Chipset and Marian Marc 2, mouse playing with Foobar2000's window :

Ok. Thanks.
So did you run the wav file off the "date cd" or create/burn an "audio cd" from the wav file and run the test ? If you burnt it what did you use to burn it ?

I copied the wav file to a "data cd" and ran the test off of the cd drive. The results were just fine i.e. same as running the wav file off the harddrive. No problems at all!

My guess is that while buring the wav file to an "audio cd" some anomalies were introduced. I will try again burning it by EAC burn feature (beta) and/or limiting drive speed while burning - instead of using maximum speed.

I will post the results.

BTW, heavy system load while playing CDDA in some simple burst way, may introduce quirks too (just like it is not recommended to rip in EAC's burst mode while there's heavy system load).
@goodsound: burning a CDDA shouldn't affect sound at all (unless you burn to some low quality media so there are errors). Playback/ripping is more likely to introduce anomalies.

It was an audio CD burned long ago. I think it was burned with Nero burning Rom.





And what if you rip the CD to the hard drive, then play the file from the hard drive ?
If you have EAC and burn another audio CD, rip it to a second file, and perform a "compare wav" action, in EAC, in order to ensure that the data was properly burned.

OK here's the deal. If I play the test track on the audio cd before the cd spins down then there is no problem, but if the cd has to spin up while doing the test or when the test starts then it screws everything up.

I am not sure if this is a power supply thing or just a synchronizing issue of rmaa of the input-output signals. The psu is 300W and I dont have any heavy duty accessories or cards running, just the regular stuff - harddrive, cd drive, agp and sound card.



then its fine. however do look at the compare results below.



Here are the results of the compare between the original/master wav file (Test Singal.wav) produced by rmaa and the same track ripped by eac(Track02.wav).




Then I just burnt another cd using ahead nero (of the same master wav file) but this time using a much slower write speed (8x). Then I ripped the track back to another wav using eac and here are the compare results. So something was different in the first burn when I used maximum speed. Oh by the way I also unchecked the option to normalize all tracks in the second attempt.





What does the 0:00:00.012 longer error mean ? Is it something to do with offset ?

It should be checked if the ripples at the cd playback graphs are due to something affecting the FFT windowing. They look like FFT window lobes.

In order to find out, a FFT with different window lengths and types could be applied to a recording of the signal.

So if I understand correctly, I should have rmaa create “resulting wav file” of the “good test” and the “bad test” also. Then apply different FFT windowing by opening the bad-test file in the “Spectrum Analysis” option and see if it matches the good-test file FFT analysis or not ?
Is that what you were referring to ?

What could possibly affect FFT windowing ?

Yes, I'm talking about that. However, it's possible that RMAA spectrum analysis is the same FFT than in test. I'd try a different program, such as Adobe Audition. You could also upload it, just the THD test part, so that we could analyse it.

About what could be causing that... I don't know, maybe some stuttering or something similar. It would be good to check it, just to be sure.

The fact that the files were normalized in the first CD explains the differences between the wavs. Audio must never be normalized.
To normalize a track means to increase its volume until the highest peak reaches 0 dB on the CD.

The longer file is probably caused by RMAA not giving a file whose lenght is a multiple of 588 samples, which is mandatory for CD burning. Nothing to worry about.

The problems measured during spin-up can be caused by the engine of the drive affecting the power supply. The effect is subtle, the highest lobe is 65 dB below the signal. It does not necessarily mean that the power supply is defective.
But they can also come from read errors occuring during the spin-up.

Now why would you write that?





Actually it doesn't have to be 0 dB. It can be any preset value. 0 dB is inadvisable because some players introduce clipping for signals at that level. Intersample overs may also be an issue when peak levels are higher than -3 dB.

btw those peaks at 20khz are from Dither. If the dithering option is unchecked those peaks disappear.