Near-Bit-Perfect ?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Just out of curiosity to see what is the quality of the digital output on my Panasonic DMP-BD85K bluray player I burnt a few test signals to an audio cd (cdda) and recorded them on my pc at cdda rate (44.1Khz/16bit). The player does output 44.1Khz. I am not sure if it outputs 16 bits or something else. Anyway to check that ?

Anyway, first I just looked at the spectrum of the recorded files. If things didn’t look good here then there was no point in going further. But they did look good. The spectrum was clean and as good as the original file that was produced by WaveGene, except I see a very small (-110db) 7hz train buried under the noise floor. When I expand the fft vertically to go -120db or lower and zoom horizontally I see it clearly. Its 7,14,21,28 …all across the entire spectrum. What would this be ? A PLL ? The recording was done using a usb soundcard so could it be the pll of the soundcard ? If there was anything about the transport or the transmission (optical), what could it be ?

Another fact that may or may not be related to this is that when I opened both the wav files to look at the actual sample values I see that the samples that are different have a difference of exactly “1”. More specifically they are greater by exactly "1". (hence the title of the thread). I have attached a screen shot of the file compare in hex mode that demonstrates this fact. The different sample values are highlighted. I can’t see any pattern here. It occurs at what appears to be random intervals. It occurs for any values (high, low, positive, negative).

It’s a -0.5db 12.5Khz sine, right side is the reference file and the left is the recorded version.

How would you explain this ? What might be going on ?
 

Attachments

  • nbp.PNG
    nbp.PNG
    143.7 KB · Views: 242
Last edited:
And here are a couple of screen shots of the fft that show the 7-8hz harmonics. The first one is the original file. The second is the recorded file. And the third is a zoom of the recorded.
 

Attachments

  • nbp_fft_orig.PNG
    nbp_fft_orig.PNG
    59.2 KB · Views: 212
  • nbp_fft_rec.PNG
    nbp_fft_rec.PNG
    70.6 KB · Views: 204
  • nbp_fft_zoom.PNG
    nbp_fft_zoom.PNG
    43.9 KB · Views: 204
My guess would be that your recording device is not bit-perfect. It is not easy to keep the bit accuracy while using computer equipment, for hundreds of reasons. Good idea would be to run the same test using another digital source, preferably just a simple CD player. If you get the same kind of differences between the original and recorded .wav, you will know that it not the player that is causing that.
 
apparently a -1 is registered every so often (7hz?) even with no signal. This is a portion of the file where there is silence before the signal started. You see those FFFF (-1) embedded between all those 0 value samples ?
 

Attachments

  • nbp_0.PNG
    nbp_0.PNG
    43.5 KB · Views: 197
Hold on a second. So you're generating a digital file, using something like Audacity, then burning this to an optical medium. You then place this inside your bluray player and play it, whilst recording the output on your computer.

The question I've got is this. Are you recording the analogue output of the bluray player or a digital output say S/PDIF?
 
I don't think this is errors caused by the SPDIF receiver. If it were they'd be more randomly distributed than this - they'd not only affect the LSB. This looks like low frequency dither is being applied to the output. It could be some kind of watermarking system for copy protection.

Its a weird one for sure.:confused:
 
Correct, over optical/toslink spdif. I kinda lazily mentioned that in my first post.

Ah yes, transmission optical, I knew I read that, for some reason it didn't register properly.

Now I understand how TOSLINK or any S/PDIF transmission might not be perfect when it comes to clock recovery, but isn't that just because of the processes involved leading to excessive jitter?

What bothers me really is the noise floor of the FFT during your recordings. For all intents and purposes it looks like it is being contaminated with some analogue signal, especially the first one. Not that I have a huge amount of experience with things like this, but I wouldn't expect there to be any peaks coming out of the noise floor if the signal was entirely digital. I am able to route the various input and output signals about my sound card and if I do a digital pass through the noise is perfectly flat, you've obviously got something popping up at 100Hz that shouldn't be there.
 
noise floor is well below -120db. Isn't that good for 16bit ?
and the 100hz spur is in the original as well and well below 16bit noise floor. see the db scale on the right axis. And I think that spur is probably just arithmetic noise of the wav file generator. so I think all that can be ignored for the purpose of this discussion. I am more curious about the +1/-1 value difference in the samples and the 7hz harmonics.
 
At low frequency (7Hz) it might be the PLL loop changing the frequency to catch-up.

If the PLL was dropping out of lock, you'd get mutes for a number of cycles at the very least. No evidence of those, therefore it can't be that.

As for low-frequency dither... come on, nobody dither in low frequency.

Well quite. Which was why I said 'looks like' :)
 
noise floor is well below -120db. Isn't that good for 16bit ?
and the 100hz spur is in the original as well and well below 16bit noise floor. see the db scale on the right axis. And I think that spur is probably just arithmetic noise of the wav file generator. so I think all that can be ignored for the purpose of this discussion. I am more curious about the +1/-1 value difference in the samples and the 7hz harmonics.

I dunno, the first one is classic analogue crud with mains borne noise permeating through on the low level stuff. The 100hz line is the usual as thrown out by the rectification process and then with harmonics at integer multiples.

The second one is 'clean' as things go, but still has the presence of that same 100Hz analogue spike and then small spikes higher up. Jitter transferred through the interface should not matter one bit as the 0s and 1s will ultimately be clocked out by the clock of the final device that plays the file.

The 0s and 1s that were originally encoded should have been 'perfect' as things go. Nothing more and nothing less etched into the CDs pits so as to be able to reproduce the sine wave. If the recording was only recording these same 0s and 1s, then why would any artefacts show up other then the sine wave? You've clearly got the presence of things in the FFT that don't reflect what should have been put on the CD and then perhaps also recorded.

If you want to plot the spectrum of the files then all you need to do is look at the 0s and 1s. It seems like that FFT program is actually playing the files back in real time to you and this isn't necessary, it also looks like it might be playing them back (at least as far as the first plot goes) whilst also looking at the analogue input of your sound card.

At the end of the day the FFT thing might be meaningless as the program that is analysing the 0s and 1s will look at the data and not anything else.
 
Are you actually losing one each time?

Each block of 4 digits, hex, represents one 16 bit byte (I am assuming).

If we look at the first one that went wrong we end up with F772 vs F672. This isn't being out by 1.

The binary for each looks like

1111 0111 0111 0010 vs
1111 0110 0111 0010

One bit has been dropped here, the 9th bit. This is like comparing 63090 with 63,346.

If we look at another though we go from 5ECC to 5FCC, this looks like.

0101 1110 1100 1100
0101 1111 1100 1100

This time around we've gained a bit. Surely if the S/PDIF thing were to abruptly correct for a phase difference it would always leave the bit it did it on as a zero, rather then a 1?

Also wouldn't the abrupt phase changes happen entirely at random? Here they always occur on the 9th or least significant bit.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.