MicroSD Memory Card Transport Project - Page 28 - diyAudio
 MicroSD Memory Card Transport Project
 User Name Stay logged in? Password
 Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs Register Donations FAQ Calendar Search Today's Posts Mark Forums Read Search

 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
 12th April 2011, 06:01 AM #271 diyAudio Member   Join Date: Aug 2008 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 06:04 AM.
 12th April 2011, 06:48 AM #272 diyAudio Member   Join Date: Aug 2008 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 07:15 AM.
 12th April 2011, 03:13 PM #273 diyAudio Member   Join Date: Aug 2008 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".
Account disabled at member's request

Join Date: Sep 2007
Location: Multiple...
Quote:
 Originally Posted by Bunpei 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.

 13th April 2011, 12:28 PM #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
diyAudio Member

Join Date: Aug 2008
Quote:
 Originally Posted by picopiyush 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
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.

diyAudio Member

Join Date: Aug 2008
Quote:
 Originally Posted by RayCtech ... 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?

diyAudio Member

Join Date: Aug 2008
Quote:
 Originally Posted by Bunpei ... 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.)

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 06:30 AM.

Account disabled at member's request

Join Date: Sep 2007
Location: Multiple...
Quote:
 Originally Posted by Bunpei 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 10:16 AM.

 16th April 2011, 01:08 PM #280 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 01:12 PM.

 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 OffTrackbacks are Off Pingbacks are Off Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post sdman Digital Line Level 5 5th September 2009 02:37 PM Jimmy154 Swap Meet 0 14th June 2006 09:15 PM YENFU Digital Source 17 24th September 2005 06:27 PM

 New To Site? Need Help?

All times are GMT. The time now is 11:31 PM.

 Home - Contact Us - Advertise - Rules - diyAudio Store - Sponsors - Archive - Privacy Statement - Terms of Service - Top - Opt-out policy

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