[indirstr8s]

Many have claimed that wav files obtained from ripping on different CD drives sound different. I had always found this very intriguing. At the RMAF in the EA room I saw Steve demonstrate that these files do sound different. He had played three files and they all sounded different.

A couple of days back I requested Steve to send me these three wav files and he obliged. I wrote a small program to convert these wave files into a more readable text format. The wav file format is very simple and I used this link to understand it.
https://ccrma.stanford.edu/courses/422/projects/WaveFormat/

The converted text files looked as below...

-------------------------------------------
ChunkID        = 0x46464952
ChunkSize      = 72455018
Format         = 0x45564157
Subchunk1ID    = 0x20746d66
Subchunk1Size  = 16
AudioFormat    = 1
NumChannels   = 2
SampleRate     = 44100
ByteRate       = 176400
BlockAlign     = 4
BitsPerSample  = 16
Subchunk2ID    = 0x61746164
Subchunk2Size  = 70795200

Stereo Data Samples (L  R) follow....

0 0
0 0
0 0
0 0
0 0
0 0
0 0
-1 0
-1 -1
---
---
---
7739 12515
9950 11382
9349 9173
6346 6270
2634 3135
142 141
-1054 -2347
-1849 -4442
-2844 -6458
-3989 -8388
---
---
---
-1 0
0 0
1 1
-1 -1
0 0
0 0
0 0
0 0
0 0
0 0
--------------------------------------------------------

Basically it contains 44 bytes of header and then the signed stereo samples. I found that the only field which was different in these headers across the three files was the "ChunkSize" field, which is effectively the file size. All the three files had different number of zero samples in the beginning and end of the data samples. I verified that once you delete some of these zero samples in the files to align them, they compared perfectly for the remaining data samples.

I feel it is only number of leading zero samples which make a difference in the sound quality. After all the DAC cannot know what the tail samples are going to be upfront. Perhaps the adequate number of zero samples at the start of the song, help to reset the D/A chip. Most of the D/A chips have delta-sigma architecture. There are highly recursive integrators in the delta-sigma modulators. The junk residues in these integrators at the beginning of the song can have a effect on the rest of the song. More ever perhaps different junk residues in the two stereo channels may affect the imaging too.
If anybody needs a primer on delta-sigma modulation (I did), this site might be useful...
http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html

I looked at the leading zero samples in the three wav file A,B,C. The file C had no leading zero samples. File B had around 100 more leading zero samples than file A. Using the above argument I speculated that file C should sound the worst and file B should sound the best. File A should sound worse than B but very close. Steve confirmed that was actually the case!

I actually think that the file B can sound still better if the number of leading zero samples are increased further. After all file A has around 450 of those while B has only a hundred more. If the number of leading zero samples really make a difference in sound quality, then even the media player can take the responsibility of sending a burst of zero samples at the start of the song. Perhaps Amarra can implement this.

[6rs]

Nice and solid piece of work! Thanks.

[ivanfx]

the next logical step would be to take some file, add a number of Zeros and check, does it sound better that way.

[claytontstanley]

indirstr8s,

It may be the case that Amarra already does this.

I remember Steve posting this comment from a previous thread:

"
Agreed.  If Amarra reduces jitter, then the Off-Ramp sounds better.  The Pace-Car does not.
The thing is that Amarra makes even the Pace-Car sound better.  This is the other 30%.
"

Steve, could the fact that Amarra pads the audio file with leading/trailing zero samples be attributing to some of this 30%?

The test for this would be: Take an unpadded file, and listen to it through Foobar. Then add leading/trailing zeros and listen again. If it sounds better, then you've got a good candidate audio file. Now listen to the unpadded and padded version in Amarra. If they both sound the same, then Amarra is padding the audio file, and you've figured out some of this 30%. Further, if they both sound the same as the padded version in Foobar, then you've figured out all of the 30%.

-Clayton

[serengetiplains]

Interesting observations and questions, guys.

[indirstr8s]

One more observation...

If MBIT+ option is used in the sample manager to convert 16bit to 24bit, almost all but few leading zero samples are replaced by non-zero but close to zero samples. None, Type1, Type2 options retain the leading zero samples.

[indirstr8s]

indirstr8s,

It may be the case that Amarra already does this.

I remember Steve posting this comment from a previous thread:

"
Agreed.  If Amarra reduces jitter, then the Off-Ramp sounds better.  The Pace-Car does not.
The thing is that Amarra makes even the Pace-Car sound better.  This is the other 30%.
"

Steve, could the fact that Amarra pads the audio file with leading/trailing zero samples be attributing to some of this 30%?

The test for this would be: Take an unpadded file, and listen to it through Foobar. Then add leading/trailing zeros and listen again. If it sounds better, then you've got a good candidate audio file. Now listen to the unpadded and padded version in Amarra. If they both sound the same, then Amarra is padding the audio file, and you've figured out some of this 30%. Further, if they both sound the same as the padded version in Foobar, then you've figured out all of the 30%.

-Clayton

That might be possible. Infact somebody did complain once, that while playing album with gapless songs, amarra created audible gaps between the songs.

[audioengr]

Here is Jon Reichbach's (Amarra engineer) response:

The thing is that any application "Should" output zeros (digital black) before the first "valid" audio sample.
     

This is not always the case though.


Amarra will Force the Gain to -144 (digital black) before audio starts.

Amarra will always apply a Fade-In (of 100ms) to the start of a song.

So Amarra will be provide the zeros (regardless of what is in the file - since we will play the correct first sample).

Steve N.

[claytontstanley]

I don't want to stretch this finding too far, but I'm wondering if this can also help explain why some people can hear differences between AccurateRips with EAC & AccurateRips with dBpoweramp. That is, audio files with the same md5 checksum that sound different.

Let's say that the md5 checksum is calculated by operating on the numbers within the region bracketed by the first and last numbers of the audio stream that are nonzero. Then, padding the audio file (adding a bunch of zeros at the beginning) would not cause the md5 checksum to change.

I hear more on the side that EAC doesn't sound as good as dBpoweramp, so maybe it's the case that EAC doesn't add any padding to the beginning of each ripped track while dBpoweramp does.

Also, interesting that one of Foobar's features is gapless playback. I wonder if this feature came at a cost. That is, to have gapless playback, you can't pad the audio files, at least unless you want to get a bit complicated, where you pad when audio playback is stopping/starting/pausing/resuming, but not between tracks. If Foobar went for simple over complicated, and decided to throw out padding to gain gapless playback, then unpadded audio files would sound particularly bad in Foobar. I'm wondering if Steve did his tests using Foobar...

[ted_b]

If this is true (and Amarra sure sounds great) could Amarra possibly do gapless playback by pre-padding the start of the next song simultaneously as it approaches the end of the current one (i.e would this require dual processors or something)?  Clearly a layman's question 

[audioengr]

I don't want to stretch this finding too far, but I'm wondering if this can also help explain why some people can hear differences between AccurateRips with EAC & AccurateRips with dBpoweramp. That is, audio files with the same md5 checksum that sound different.

Let's say that the md5 checksum is calculated by operating on the numbers within the region bracketed by the first and last numbers of the audio stream that are nonzero. Then, padding the audio file (adding a bunch of zeros at the beginning) would not cause the md5 checksum to change.

I believe it will change.  It uses both the data and the order.

I hear more on the side that EAC doesn't sound as good as dBpoweramp, so maybe it's the case that EAC doesn't add any padding to the beginning of each ripped track while dBpoweramp does.

This is certainly possible, and could be compared.

Also, interesting that one of Foobar's features is gapless playback. I wonder if this feature came at a cost. That is, to have gapless playback, you can't pad the audio files, at least unless you want to get a bit complicated, where you pad when audio playback is stopping/starting/pausing/resuming, but not between tracks. If Foobar went for simple over complicated, and decided to throw out padding to gain gapless playback, then unpadded audio files would sound particularly bad in Foobar. I'm wondering if Steve did his tests using Foobar...

I used Foobar 0.8.3, iTunes and iTunes with Amarra.  Same result.

Steve N.

[indirstr8s]

I just wanted to make clear that my theory which I laid out in the topic is highly speculative. But a couple of things I am pretty sure of...

a) The files do sound different. More so in the demonstration by Steve at the RMAF, and to many other s too.
b) These files are ordinarily similar. Even the headers are exact same. The files sizes were different initially as I had tagged them by accident in the itunes and an extra "chunk" got added in the end. But After I began with fresh files again even the file sizes and the headers are exactly the same. Only difference is the number of leading and trailing zero samples.

[claytontstanley]

So, padding is causing this effect, and you can hear this effect with all three players. Then, it must be the case that either [1] all three players are not adding additional padding to the file, or [2] they are all not adding enough padding to the file.

Because of Steve's previous post about Amarra, we know it's the case that Amarra inserts silence before audio playback begins (i.e., it pads the audio file), so [1] can't be true. But for [2], it would have to be the case that the amount of padding the Amarra (and others) are adding isn't dwarfing the small amount of padding differences in the actual files, and I find this particularly hard to believe... So I can't see [2] being right either...

As an alternative, what if there is actually a difference between padding the file itself (i.e., adding leading zeros) and inserting silence before the file starts playing (i.e., having the player 'play' leading zeros). Is it safe to say that these processes are exactly the same?

-Clayton

[audioengr]

So, padding is causing this effect, and you can hear this effect with all three players. Then, it must be the case that either [1] all three players are not adding additional padding to the file, or [2] they are all not adding enough padding to the file.

Because of Steve's previous post about Amarra, we know it's the case that Amarra inserts silence before audio playback begins (i.e., it pads the audio file), so [1] can't be true. But for [2], it would have to be the case that the amount of padding the Amarra (and others) are adding isn't dwarfing the small amount of padding differences in the actual files, and I find this particularly hard to believe... So I can't see [2] being right either...

As an alternative, what if there is actually a difference between padding the file itself (i.e., adding leading zeros) and inserting silence before the file starts playing (i.e., having the player 'play' leading zeros). Is it safe to say that these processes are exactly the same?

-Clayton

There is a difference between adding silence or "idle" signal and increasing the zeros in the file itself.

Steve N.

[claytontstanley]

So, padding is causing this effect, and you can hear this effect with all three players. Then, it must be the case that either [1] all three players are not adding additional padding to the file, or [2] they are all not adding enough padding to the file.

Because of Steve's previous post about Amarra, we know it's the case that Amarra inserts silence before audio playback begins (i.e., it pads the audio file), so [1] can't be true. But for [2], it would have to be the case that the amount of padding the Amarra (and others) are adding isn't dwarfing the small amount of padding differences in the actual files, and I find this particularly hard to believe... So I can't see [2] being right either...

As an alternative, what if there is actually a difference between padding the file itself (i.e., adding leading zeros) and inserting silence before the file starts playing (i.e., having the player 'play' leading zeros). Is it safe to say that these processes are exactly the same?

-Clayton

There is a difference between adding silence or "idle" signal and increasing the zeros in the file itself.

Steve N.

Now that's interesting,

At first pass (and 2nd and 3rd passes over the past few days), I can't come up with a mental model where the DAC wouldn't see these two types of 'silence' as exactly the same. Any hints on what I'm missing, or maybe some reading material that would help me out?

Thanks,
-Clayton

[audioengr]

So, padding is causing this effect, and you can hear this effect with all three players. Then, it must be the case that either [1] all three players are not adding additional padding to the file, or [2] they are all not adding enough padding to the file.

Because of Steve's previous post about Amarra, we know it's the case that Amarra inserts silence before audio playback begins (i.e., it pads the audio file), so [1] can't be true. But for [2], it would have to be the case that the amount of padding the Amarra (and others) are adding isn't dwarfing the small amount of padding differences in the actual files, and I find this particularly hard to believe... So I can't see [2] being right either...

As an alternative, what if there is actually a difference between padding the file itself (i.e., adding leading zeros) and inserting silence before the file starts playing (i.e., having the player 'play' leading zeros). Is it safe to say that these processes are exactly the same?

-Clayton

There is a difference between adding silence or "idle" signal and increasing the zeros in the file itself.

Steve N.

Now that's interesting,

At first pass (and 2nd and 3rd passes over the past few days), I can't come up with a mental model where the DAC wouldn't see these two types of 'silence' as exactly the same. Any hints on what I'm missing, or maybe some reading material that would help me out?

Thanks,
-Clayton

The control frames that contain information about the file are not there in the idle signal, for obvious reasons.

Steve N.