Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 12th April 2011, 05:01 AM   #271
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Default Padding residual bits for 24 bit data

SDTrans192 outputs I2S signal of BCLK frequency, 64*fs. This means formal bit length of one channel data is always 32 bit while effective bit length of actual data is 16, 24, or 32 bit depending on its sources. Therefore, in the case of 16 or 24 bit audio data, residual 16 or 8 bit space must be padded with dummy data.

As you may know, LPCM data in audio file is represented in a signed integer representation of 2's compliment.
Current FPGA program on SDTrans192 pads binary 0 for a positive value and binary 1 for a negative value. Originally, padding 0 for all values were adopted. One over seas user requested changing the method and we made the change because two users including the requesting person said "The new method brings better sonic effect."
However, the current way of padding, "binary 0 for positive value and binary 1 for negative value" is mathematically incorrect.

When we extend, for example, 24 bit signed integer to 32 bit signed integer, a method called "signed extension" should be used. In this operation, the sign of original integer is padded for "left side extended space"; binary 1 for a negative value and binary 0 for a positive value, respectively.
However, if we use this direct value for a play, dB value becomes small. Therefore, we should multiply 8 bit number. This requires "arithmetic left shift" that pads eight 0 to its right space. This operation is not sign dependent but involving only fixed 0.

I prefer a pragmatic approach. Even if the operation is "scientifically unsound", I agree with it as long as it results "better sounds".
One practical explanation supporting the "operation padding binary 0 for positive value and binary 1 for negative value" might be "possible favorable effects on power supply conditions for related digital circuits".

Last edited by Bunpei; 12th April 2011 at 05:04 AM.
  Reply With Quote
Old 12th April 2011, 05:48 AM   #272
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Default Carmen Habanera Fantasia 352.8 kHz/32 bit audio source

I obtained "Carmen Habanera Fantasia" 352.8 kHz/32 bit WAV file from one of my acquaintances. The file was once downloadable from this page;
Complimentary High Resolution Downloads Courtesy of First Impression Music (24/88.2, 24/176.4, 32/352.8) | Computer Audiophile
The file is not "integer LPCM" but "floating point LPCM".

As SDTrans192 can't handle 32bit files of 352.8 kHz, we converted the original file into 352.8 kHz/24 bit and 176.4 kHz/32 bit. I felt that the tunes were very "Hi-fi".

Just recently, I could examine FFT spectra of the source and found high range components above 22 kHz is almost removed by a very sharp filter.
I guess it is re-recorded or re-sampled from a master tape or HDD originally recorded for a CD release.
Moreover, floating point LPCM may denote it's not a raw recording but an edited deliverable.

Contrarily, 2L DXD sources are respectful genuine DXD sources.

For your information, I understand that the name, DXD, was given by Digital Audio Denmark (DAD) for a usual LPCM WAV format for 352.8 kHz or 384 kHz.
Therefore, there is no formal independent standard document for DXD is available. The WAV file format produced by the combination of ProTools and DAD AX24 might be a de facto standard for DXD. I believe the WAV file format released by 2L can be regarded as "genuine".

Last edited by Bunpei; 12th April 2011 at 06:15 AM.
  Reply With Quote
Old 12th April 2011, 02:13 PM   #273
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Default Bit perfect play of PCM audio data

SDTrans192 can play only WAV format audio files of integer LPCM representation. It can play neither FLAC, MP3, nor floating point PCM though it can handle 32 bit data up to 192 kHz sampling rate.
The MCU(CPU) device is too busy for executing a task of transferring raw integer LPCM data from SD memory to FPGA that generates I2S signals. No such jobs as format conversion is available at all.
This means its play is completely "bit perfect" for LPCM integer data. No room for conversion.

On the other hand, usual commercial audio DAC devices are compatible only for LPCM integer input data even if the bit length is 32 bit. I have never looked at any commercial audio DAC chip that accepts raw floating point 32 bit data for input. Therefore, feeding a DAC chip with floating point PCM data is quite ridiculous. I have once given floating point 32 bit data to ES9018 from SDTrans by faking data type. The tones obtained were garbled.

If you can play a WAV file of floating point PCM by feeding a DAC chip with a data prepared on computer, a program on a computer must be converting floating point numbers into corresponding integer numbers.
Of course, such automatic conversion is very convenient.
However, it's not "bit perfect".
  Reply With Quote
Old 12th April 2011, 10:20 PM   #274
Account disabled at member's request
 
Join Date: Sep 2007
Location: Multiple...
Quote:
Originally Posted by Bunpei View Post
I obtained "Carmen Habanera Fantasia" 352.8 kHz/32 bit WAV file from one of my acquaintances. The file was once downloadable from this page;
Complimentary High Resolution Downloads Courtesy of First Impression Music (24/88.2, 24/176.4, 32/352.8) | Computer Audiophile
The file is not "integer LPCM" but "floating point LPCM".

As SDTrans192 can't handle 32bit files of 352.8 kHz, we converted the original file into 352.8 kHz/24 bit and 176.4 kHz/32 bit. I felt that the tunes were very "Hi-fi".

Just recently, I could examine FFT spectra of the source and found high range components above 22 kHz is almost removed by a very sharp filter.
I guess it is re-recorded or re-sampled from a master tape or HDD originally recorded for a CD release.
Moreover, floating point LPCM may denote it's not a raw recording but an edited deliverable.

Contrarily, 2L DXD sources are respectful genuine DXD sources.

For your information, I understand that the name, DXD, was given by Digital Audio Denmark (DAD) for a usual LPCM WAV format for 352.8 kHz or 384 kHz.
Therefore, there is no formal independent standard document for DXD is available. The WAV file format produced by the combination of ProTools and DAD AX24 might be a de facto standard for DXD. I believe the WAV file format released by 2L can be regarded as "genuine".
Hi Bunpei,

I used you SDTrans192 (not rev 3.0) to verify the 384k operation of my DAC some time back in time.
I expect I then also verified that the SDTrans192 prior to the rev 3.0 technically are able to operate ate 384k

I simply switched the clocks on the SDTrans192 so it actually clocked the data out at 384k.
I know this was not a true 384k test as it was a 352.8k file that was clocked at 384k, but I was able to verify that both the FPGA on the SDTrans192 and my DAC performed perfect at 384k samplerates - and that was my goal at the time - to verify the flawless 384k operation of my DAC.
  Reply With Quote
Old 13th April 2011, 11:28 AM   #275
diyAudio Member
 
Join Date: Apr 2011
hey can anybody tell me how to make simple mp3 player using analog devices' DAC IC(ad1852) allowing file access from a micro SD with the help of an 8051
  Reply With Quote
Old 13th April 2011, 02:28 PM   #276
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally Posted by picopiyush View Post
hey can anybody tell me how to make simple mp3 player using analog devices' DAC IC(ad1852) allowing file access from a micro SD with the help of an 8051
Have you ever read this page?
VLSI Solution-VS1053 Evaluation Kit
If your requirement is limited to 44.1 kHz/16 bit or 48 kHz/16 bit, VS1053b chip would be able to output I2S signals for AD1852.
The schematic linked to the web page above may help you.
  Reply With Quote
Old 13th April 2011, 02:37 PM   #277
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally Posted by RayCtech View Post
... I simply switched the clocks on the SDTrans192 so it actually clocked the data out at 384k.
I know this was not a true 384k test as it was a 352.8k file that was clocked at 384k, but I was able to verify that both the FPGA on the SDTrans192 and my DAC performed perfect at 384k samplerates ...
Hi, RayCtech, Welcome you back to this thread!

The result is very interesting. You have hacked your SDTrans.
I will tell this result to Chiaki.
However, we have no music audio source of genuine 384 kHz/ 24bit recording. Do you think 2L will release such sources?
  Reply With Quote
Old 16th April 2011, 05:25 AM   #278
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally Posted by Bunpei View Post
... This requires "arithmetic left shift" that pads eight 0 to its right space. This operation is not sign dependent but involving only fixed 0.
Just recently, I found an illustration that shows fixed "0" padding on residual bit spaces in "S/PDIF Sub Frame". (In this figure, as MSB is located in the right-hand side, right and left notation is reverted to that in my explanation before.)

Click the image to open in full size.

The original blog article(written in Japanese)

?????????PC ????? ???: #24 Digital Audio????????S/PDIF????4?

presented by a president of RATOC Systems explains S/PDIF fundamentals very well in a rigorous manner. (The president is an excellent engineer who is also an audiophile.)

I'd like to explain one important point on an error correction mechanism in S/PDIF here. This topic was covered in the blog article.

One sub frame of S/PDIF consists 32 bit. A main 24 bit part is assigned to LPCM data, 4 bit leading part for "preamble(sync)", and 4 bit trailing part for "flag & status". In the last of the flag & status part, there is one "Parity" bit. If a S/PDIF receiver calculates own 1 parity bit value and compares it to the parity bit value in the flag part, the receiver is able to know whether the sub frame is broken or not. As you may know very well, 1 bit parity information can just tell merely that the value is valid or invalid. No value correction is possible base on just one bit. For error correction, more redundant bits are necessary.
In a secured data communication scheme, when a parity error is detected in a data frame, a re-transmission mechanism for the data frame is to be executed. For example, TCP protocol used in the Internet sometimes invoke re-transmissions if necessary.
In our S/PDIF protocol, no re-transmission mechanism is implemented. The communication involved is just one way. No re-transmission request can be sent from receiver to transmitter. Therefore, no data correction is available on S/PDIF data transmission.

If you feel the tunes through S/PDIF line is better than I2S because of its error handling mechanism, it might be due to a placebo effect.

Last edited by Bunpei; 16th April 2011 at 05:30 AM.
  Reply With Quote
Old 16th April 2011, 09:09 AM   #279
Account disabled at member's request
 
Join Date: Sep 2007
Location: Multiple...
Quote:
Originally Posted by Bunpei View Post
As you may know very well, 1 bit parity information can just tell merely that the value is valid or invalid. No value correction is possible base on just one bit. For error correction, more redundant bits are necessary.
If you feel the tunes through S/PDIF line is better than I2S because of its error handling mechanism, it might be due to a placebo effect.
You said it "because of its error handling mechanism"..

Disregarding all other aspects of the differences between SPDIF and I2S and focusing only on the "error handling mechanism" of the SPDIF then giving the credits of the error handling mechanism to the placebo effect is a very strange technical conclusion ? ?

Here are a very simplified example:
If we use a SDTrans192 as a source and two DAC´s as the destination - one with direct I2S input - the other with a SPDIF receiver delivering I2S to the DAC.
The FPGA on the SDTrans192 clocks out I2S signals and the I2S signals are routed both to the SPDIF transmitter (onboard the SDTrans192) and directly to the I2S output pins.
One DAC receives the SPDIF signal and the other the direct I2S signals.

Lets say that we will send three samples:
1. A positive sample at 0dB.
2. A positive sample at -6dB.
3. A positive sample at 0dB.

Lets say that we just have transmitted the first error free positive sample at 0dB (positive clipping/maximum - a signed 16bit integer two´s complement value of 32767).

Then we are transmitting the positive sample at -6dB (a signed 16bit integer two´s complement value of 16383), but some electrical disturbance interferes and the MSB in both the I2S and the SPDIF transmission are changed to a "1" - changing the sample to a NEGATIVE value...

With I2S the decoded signal will then go from a (the first sample) positive sample (at 0dB below positive clipping) to a negative sample at -6dB (a signed 16bit integer two´s complement value of -16385) above negative clipping..

With SPDIF it could depending on the selected behavior of the error handling mechanism either be a zero value (a signed 16bit integer two´s complement value of 0), the last known good value a (signed 16bit integer two´s complement value of 32767) or the actual value (in error) (a signed 16bit integer two´s complement value of -16385) that are given to the DAC..

Then we are transmitting the third error free positive sample at 0dB (positive clipping/maximum - a signed 16bit integer two´s complement value of 32767).

How on earth you can assign the second samples (sample in error via SPDIF) conditional behavior to placebo I would like to see your logical or mathematical explanation of...

Last edited by RayCtech; 16th April 2011 at 09:16 AM.
  Reply With Quote
Old 16th April 2011, 12:08 PM   #280
Bunpei is offline Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Dear RayCTech,

Your discussion in theory is completely correct. I2S has a fatal defect.
My technical background is in a computer science. No data transmission without error corrections can be acceptable in the field in principle.

Therefore, we must do our best for eliminating transmission errors in I2S. In my system where SDTrans192 Rev. 2.1 that you kindly upgraded power supplies for us is connected to TPA Buffalo II via I2S. The wires are shielded and wire length does not exceed an inch.

I can prove that absolutely no errors that you worry happen in my system.
If any erroneous bit flip occurs so frequently, you will always detect a large spike noise. You might easily think the system would be defective. I have never heard such spike noises.

Lets say that we will send 10,000 samples:
1. A zero sample at -96.3dB. 0b0000000000000000
2. A zero sample at -96.3dB. 0b0000000000000000
....
10000. A zero sample at -96.3dB. 0b0000000000000000
When
50. A zero sample at -96.3dB. 0b0000000000000000
is mis-received as
50. A negative sample at 0.0dB. 0b1000000000000000

If the erroneous bit flip occurs so frequently, every datasheet of receiver chip would excuse, "We handle data errors in this way, ....". Have your ever read such descriptions?

If you want to argue your point, please show us your clear actual recorded and reproducible evidences that bit flip errors happen during I2S connection.

Bunpei

Last edited by Bunpei; 16th April 2011 at 12:12 PM.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Usb Memory Stick/flash Card sdman Digital Line Level 5 5th September 2009 01:37 PM
FS: AMD 1 GHz CPU, motherboard, 256MB RAM, video card, power supply, network card Jimmy154 Swap Meet 0 14th June 2006 08:15 PM
My CD-Transport project YENFU Digital Source 17 24th September 2005 05:27 PM


New To Site? Need Help?

All times are GMT. The time now is 09:30 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2