SACD Iso
Dear Bunpei,
Let me also support the SOUND_Ray 's request to overcome the limit of 32GB for SDHC.
I would also add the following request: the ability to read stereo channel from a SACD ISO image. For example, there is a foobar plugin for this capability. I do not know if the ISO extraction and DSD conversion is a process that engages the CPU excessively, but many archives are in multichannel ISO format.
Thank you
Dear Bunpei,
Let me also support the SOUND_Ray 's request to overcome the limit of 32GB for SDHC.
I would also add the following request: the ability to read stereo channel from a SACD ISO image. For example, there is a foobar plugin for this capability. I do not know if the ISO extraction and DSD conversion is a process that engages the CPU excessively, but many archives are in multichannel ISO format.
Thank you
Yes SOUND_rays - I replied a while ago...
And yes, 64 GB has been around fo a while - so why restrict to 32GB's? 128 is on our doorstep so why not increase the address space to have a smooth transition to the near future - 1TB shouldnt be that far away.
Now, I'm curious of the silence in this thread which I don't feel to be very welcoming. No posts since the 18'th of Jan.? Strange...
Silence and lack of information makes me a dull boy so now I might not make it to the choir of the choosen ones.
Bunpei and Chiaki - you want to sell -why don't you? Is there a doubt maybe that anyone outside the choosen ones could ever give enough credit to your design? But what would you ever achieve if you only listen to the believers?
Brgds anyway - life and technology moves on.
And yes, 64 GB has been around fo a while - so why restrict to 32GB's? 128 is on our doorstep so why not increase the address space to have a smooth transition to the near future - 1TB shouldnt be that far away.
Now, I'm curious of the silence in this thread which I don't feel to be very welcoming. No posts since the 18'th of Jan.? Strange...
Silence and lack of information makes me a dull boy so now I might not make it to the choir of the choosen ones.
Bunpei and Chiaki - you want to sell -why don't you? Is there a doubt maybe that anyone outside the choosen ones could ever give enough credit to your design? But what would you ever achieve if you only listen to the believers?
Brgds anyway - life and technology moves on.
Last edited:
"But what would you ever achieve if you only listen to the believers?"
Now, if you are still interested in sell I might be intrested to buy if the price have the slightest correleance to the price of the parts. As I see it now you Bunpei and Chiaki are holding this back due to one of two reasons:
1: You can sell the next one with 48bits/640khz with a maximum of 64Gb storage for at least 100$ more (whenever that will be called today). Hereby forcing the believers to give another 75$ more to be able to hopefully flash - or 175$ to buy an eprom (if anyone remember these).
2: You don't know how to increase the storagespace - the question pops up at once - how did you get this far... Increasing from 2G -> 32G. Not even once what I know of being promptly directed to the vendors area??? Strange... I believe you have a business plan and are still lurking outside the vendors thread for some reason (believers=money?)
As I see it - the best DIY (Admin - please confirm so I don't loose my childish believes.) is when someone comes up with the best (as few money involved as possible) idea of how to enhance audio quality AS POSSIBLE. The rest is just gaining a few bucks here or there and if believe is sufficient - gain a bit of bigger bucks (of course keep the technology low so you can gain more in the future with enhancements.) OK, the receipe is out...
Sorry, I behave like this when worship is the expected manner and answers are few...
These are the thoughts that pops up in my mind after thinking about it for an hour after I started to search for this thread...
So where are we Bunpei/Chiaki-Sans? Is this to be real or should we just accept the fact that this is the ultimate piece of technology revealed by the textual reviews of the choosen ones (even if it only handles 32G)?
And yes SOUND_rays - you newer came back what I'm aware of. But then again - emails can be lost so please try again.
Brgds anyway to all - life and technology moves on.
Now, if you are still interested in sell I might be intrested to buy if the price have the slightest correleance to the price of the parts. As I see it now you Bunpei and Chiaki are holding this back due to one of two reasons:
1: You can sell the next one with 48bits/640khz with a maximum of 64Gb storage for at least 100$ more (whenever that will be called today). Hereby forcing the believers to give another 75$ more to be able to hopefully flash - or 175$ to buy an eprom (if anyone remember these).
2: You don't know how to increase the storagespace - the question pops up at once - how did you get this far... Increasing from 2G -> 32G. Not even once what I know of being promptly directed to the vendors area??? Strange... I believe you have a business plan and are still lurking outside the vendors thread for some reason (believers=money?)
As I see it - the best DIY (Admin - please confirm so I don't loose my childish believes.) is when someone comes up with the best (as few money involved as possible) idea of how to enhance audio quality AS POSSIBLE. The rest is just gaining a few bucks here or there and if believe is sufficient - gain a bit of bigger bucks (of course keep the technology low so you can gain more in the future with enhancements.) OK, the receipe is out...
Sorry, I behave like this when worship is the expected manner and answers are few...
These are the thoughts that pops up in my mind after thinking about it for an hour after I started to search for this thread...
So where are we Bunpei/Chiaki-Sans? Is this to be real or should we just accept the fact that this is the ultimate piece of technology revealed by the textual reviews of the choosen ones (even if it only handles 32G)?
And yes SOUND_rays - you newer came back what I'm aware of. But then again - emails can be lost so please try again.
Brgds anyway to all - life and technology moves on.
Last edited:
To SOUND_Rays, hirez69 and Turbon,
I'm sorry that I had held your posts unanswered for a long time.
I had not enough time because of my private reasons.
Frankly speaking, your request on a new capability of handling SDXC card is too challenging as of now.
As you may know, SDTrans uses a 8 bit microprocessor of C8051 architecture and the firmware is coded in C8051 assembly language. (That's why we can get the highest performance of the MCU)
A task of handing TB sized file systems is too much for a tiny 8 bit processor.
In the case of SDXC memory card of the volume size more than 64GB, the file system adopted there is Microsoft proprietary exFAT. Not so much free information on its specification is available. Chiaki and Bunpei are not a big commercial vendor, but just digital audio hobbyists. Therefore, we can't afford license fee required for developing SDXC technology incorporated products.
When necessary technical information on SDXC memory card and exFAT just becomes available for a computer hobbyist, Chiaki may try to use the technology.
As for a reading DSD data in ISO image file obtained by SONY PlayStation3, it is not a task for a simple memory card player. Please use a rich CPU power and memories in PC for that purpose.
I hope you can imagine technical limitations properly.
Bunpei
I'm sorry that I had held your posts unanswered for a long time.
I had not enough time because of my private reasons.
Frankly speaking, your request on a new capability of handling SDXC card is too challenging as of now.
As you may know, SDTrans uses a 8 bit microprocessor of C8051 architecture and the firmware is coded in C8051 assembly language. (That's why we can get the highest performance of the MCU)
A task of handing TB sized file systems is too much for a tiny 8 bit processor.
In the case of SDXC memory card of the volume size more than 64GB, the file system adopted there is Microsoft proprietary exFAT. Not so much free information on its specification is available. Chiaki and Bunpei are not a big commercial vendor, but just digital audio hobbyists. Therefore, we can't afford license fee required for developing SDXC technology incorporated products.
When necessary technical information on SDXC memory card and exFAT just becomes available for a computer hobbyist, Chiaki may try to use the technology.
As for a reading DSD data in ISO image file obtained by SONY PlayStation3, it is not a task for a simple memory card player. Please use a rich CPU power and memories in PC for that purpose.
I hope you can imagine technical limitations properly.
Bunpei
Chiaki and Bunpei have made a prototype of �gMicroSD Memory Card Transport�h. (In the picutre below, you can look at just black margin of the memory card under the PCB board in right hand. Some colored cablings are for I2S signals.)
http://www.chiaki.cc/Timpy/images/70-i2s2.jpg
Our tiny MicroSD Memory Card Transport plays 16bit/48KHz WAV files stored on a MicroSD Memory Card (MicroSD in short) and outputs 16bit/48KHz I2S signals to a DAC device. The sound produced by the system is very clear, detailed and natural taste of �gpure-audio�h quality in spite of its low cost for materials and we are much satisfied with the result.
We believe that a jitter is very little and data processed here are almost bit-perfect though we have not confirmed them by any measurements.
In the transport, a microcontroller of 8bit 8051 architecture, C8051F316 12MHz, with specially developed firmware reads a WAV file on a MicroSD and sends the data to VLSI VS1053b codec chip.
VLSI Solution-VS1053 - Ogg Vorbis / MP3 / AAC / WMA / FLAC / MIDI Audio Decoder / Encoder Chip
VS1053b codec converts the PCM data into I2S signals based on 12.288MHz system clock generated by TXCO, Fox XPRESSO Crystal Oscillator.
http://www.foxonline.com/pdfs/FXO_HC73.pdf
how much it costs and I am in Indonesia where I can buy?
There are 16bits variants available for years back - I haven't checked for 32 bits or 64 bits... They are all using the same mnemonics but the address and dataspaces have grown and probably new instructions have found their way in... 8 bit code hmmm, this has buggered me for a while.
Brgds
To SDTrans384 users and To those who are interested in the player
I'm very sorry that I have not replied to your e-mails and posts here.
I have my private matters to solve and prices and costs had not been finalized so long period.
Chiaki finalized a version of firmware for MCU and FPGA program for DSD play at last. He needed to spend more time than he had expected to minimize a "click" noise between DSD source files. We are ready to distribute a new configuration ROM of FPGA now.
By using the new firmware and FPGA configuration EEPROM, you can seamlessly play stereo PCM ( 44.1 kHz/24 bit - 384 kHz/32 bit) and DSD64,128,256 sources. No additional hardware change is required in principle. When you adopt ES9018-based DAC with a stereo configuration, you need not to change hardware wiring depending on PCM and DSD.
At the same time, a new batch of SDTrans384 that incorporates the new firmware and EEPROM will get ready for shipping hopefully at the end of next week. Therefore, I have started sending a private e-mail to those who requested estimates to me by a usual internet e-mail.
As for the "Sync Oscillators Sub-boards Option for ES9018", we have not been able to finalized its price yet. So, I am sending a tentative estimate to those who requested a price. Some people may request more detailed technical and quality explanation that can justify the high price of this option (More expensive than the main board of SDTrans384!)
I will begin posting those information soon here.
Bunpei
I'm very sorry that I have not replied to your e-mails and posts here.
I have my private matters to solve and prices and costs had not been finalized so long period.
Chiaki finalized a version of firmware for MCU and FPGA program for DSD play at last. He needed to spend more time than he had expected to minimize a "click" noise between DSD source files. We are ready to distribute a new configuration ROM of FPGA now.
By using the new firmware and FPGA configuration EEPROM, you can seamlessly play stereo PCM ( 44.1 kHz/24 bit - 384 kHz/32 bit) and DSD64,128,256 sources. No additional hardware change is required in principle. When you adopt ES9018-based DAC with a stereo configuration, you need not to change hardware wiring depending on PCM and DSD.
At the same time, a new batch of SDTrans384 that incorporates the new firmware and EEPROM will get ready for shipping hopefully at the end of next week. Therefore, I have started sending a private e-mail to those who requested estimates to me by a usual internet e-mail.
As for the "Sync Oscillators Sub-boards Option for ES9018", we have not been able to finalized its price yet. So, I am sending a tentative estimate to those who requested a price. Some people may request more detailed technical and quality explanation that can justify the high price of this option (More expensive than the main board of SDTrans384!)
I will begin posting those information soon here.
Bunpei
Dear Lucky Hawk,
I'm very sorry that I had not replied to your post.
To our regret, the board is not on sale anymore. It was just our initial technical challenge.
Bunpei
Sync oscillators subboard option for ES9018 DAC
1. Introduction
Chiaki and Bunpei used to input I2S signals to ES9018-based DAC boards.
(ESS ES9018 Evaluation board, TPA Buffalo32s, TPA Buffalo II, TPA Buffalo III)
We found that achieving a lower DPLL bandwidth setting was very difficult for I2S input even if we used oscillators of low phase noise profiles on both the transport side and the ES9018 DAC side under an asynchronous master clock injection to the DAC chip.
Chiaki considered and inferred an internal mechanism of the DPLL adopted in ES9018 and came to the assumption that a quantization error in a time domain can't be ignored in the case of I2S input as long as an asynchronous master clocking scheme is used.
Then he decided to test "a synchronous master clocking method" using SDTrans384 and ESS ES9018 Evaluation board.
1. Introduction
Chiaki and Bunpei used to input I2S signals to ES9018-based DAC boards.
(ESS ES9018 Evaluation board, TPA Buffalo32s, TPA Buffalo II, TPA Buffalo III)
We found that achieving a lower DPLL bandwidth setting was very difficult for I2S input even if we used oscillators of low phase noise profiles on both the transport side and the ES9018 DAC side under an asynchronous master clock injection to the DAC chip.
Chiaki considered and inferred an internal mechanism of the DPLL adopted in ES9018 and came to the assumption that a quantization error in a time domain can't be ignored in the case of I2S input as long as an asynchronous master clocking scheme is used.
Then he decided to test "a synchronous master clocking method" using SDTrans384 and ESS ES9018 Evaluation board.
Sync oscillators subboard option for ES9018 DAC
2. Generating synchronous master clock of 90.3168MHz/98.304MHz
SDTrans384 board has two low phase noise crystal oscillators of frequencies, 22.5792MHz and 24.576MHz made by NDK. At the first design of the board, raw output signals of these oscillators were directly connected to MCLK output pin. However, this signal had not been used for ES9018-based DAC.
As we had known that MCLK frequency higher than 90MHz is essential for playing 352.8kHz/24bit PCM(DXD) files without noises on OSF=ON mode, Chiaki added 4x multiplier DPLL circuit in FPGA. Then we have obtained an synchronous MCLK of 90.3168MHz/98.304MHz for output. In this context, "synchronous" means MCLK and other I2S signals, BCLK, LRCLK, SDAT are synchronous. The MCLK output is available on a standard SDTrans384 board kit that will be distributed in coming April.
Bunpei recognized a remarkable sonic improvement when he applied the synchronous MCLK of 90.3168MHz/98.304MHz to ES9018 chip on Buffalo II board for the first time. At the same time, this clocking scheme made us set "DPLL Bandwidth" parameter at "the lowest" even for I2S input and OSF=ON condition for 352.8kHz/24bit PCM.
2. Generating synchronous master clock of 90.3168MHz/98.304MHz
SDTrans384 board has two low phase noise crystal oscillators of frequencies, 22.5792MHz and 24.576MHz made by NDK. At the first design of the board, raw output signals of these oscillators were directly connected to MCLK output pin. However, this signal had not been used for ES9018-based DAC.
As we had known that MCLK frequency higher than 90MHz is essential for playing 352.8kHz/24bit PCM(DXD) files without noises on OSF=ON mode, Chiaki added 4x multiplier DPLL circuit in FPGA. Then we have obtained an synchronous MCLK of 90.3168MHz/98.304MHz for output. In this context, "synchronous" means MCLK and other I2S signals, BCLK, LRCLK, SDAT are synchronous. The MCLK output is available on a standard SDTrans384 board kit that will be distributed in coming April.
Bunpei recognized a remarkable sonic improvement when he applied the synchronous MCLK of 90.3168MHz/98.304MHz to ES9018 chip on Buffalo II board for the first time. At the same time, this clocking scheme made us set "DPLL Bandwidth" parameter at "the lowest" even for I2S input and OSF=ON condition for 352.8kHz/24bit PCM.
Sync oscillators subboard option for ES9018 DAC
3. Locating master clock oscillators on DAC board side
When Chiaki and Bunpei started this SDTrans project, we established one policy;
"Avoid using PLL in clocking"
Therefore, in the next step, Chiaki started a new design of locating 90.3168MHz/98.304MHz crystal oscillators on the DAC board side. In this configuration, the oscillator output signals are injected directly to ES9018 chip with the shortest wiring. At the same time, forked outputs are sent from the DAC side to the transport, SDTrans side and the master clock signals are divided by 4 so that it may be compatible to original NDK oscillators on board.
Here, we chosen NDK crystal oscillators of low phase noise profile of which frequencies are 90.3168MHz/98.304MHz based on a recommendation of the company. However, its unit price is 15,000 JPY = 180 USD! Moreover, its output signal level is LVPECL and we need a buffer in order to make compatible CMOS.
Beside that, Chiaki adopted such a switching mechanism for the two oscillators that a command sent from the SDTrans side depending on the sampling frequency of audio source files though I2C line controls a switching buffer located in the DAC side.
These features make the sub board to be attached on the DAC side very expensive.
3. Locating master clock oscillators on DAC board side
When Chiaki and Bunpei started this SDTrans project, we established one policy;
"Avoid using PLL in clocking"
Therefore, in the next step, Chiaki started a new design of locating 90.3168MHz/98.304MHz crystal oscillators on the DAC board side. In this configuration, the oscillator output signals are injected directly to ES9018 chip with the shortest wiring. At the same time, forked outputs are sent from the DAC side to the transport, SDTrans side and the master clock signals are divided by 4 so that it may be compatible to original NDK oscillators on board.
Here, we chosen NDK crystal oscillators of low phase noise profile of which frequencies are 90.3168MHz/98.304MHz based on a recommendation of the company. However, its unit price is 15,000 JPY = 180 USD! Moreover, its output signal level is LVPECL and we need a buffer in order to make compatible CMOS.
Beside that, Chiaki adopted such a switching mechanism for the two oscillators that a command sent from the SDTrans side depending on the sampling frequency of audio source files though I2C line controls a switching buffer located in the DAC side.
These features make the sub board to be attached on the DAC side very expensive.
Hmmm, I missed that part somwhere and the discussion of the address space of the 8051... Bunpei, do you still want me as a customer if it handles 32GB's?
Brgds
SDTrans384 handles a SDHC memory card, of which maximum volume size is 32GB and the maximum file size is 4GB. I'm afraid that you may think the max file size 4GB is not enough for a long classical music of DSD256 recording.
Chiaki does not use any direct address space of C8051 for processing audio data. The MCU is just used to issue read-out commands to the memory card. Its main task is to track FAT cluster chains.