... if you want to live up to the premise of the so called NOS DAC, with 44.1/16 base material the best you can do is applying your own DF function with the apodizing™ attribute, so it cuts down the pre encoded pre-ringing that was there to begin with . Then feed this 24/192 into an accurate DA like PCM1704(?). Bye-bye pre ringing.
But once you apply your own DF function , why would you call it NOS in the first place, just because it has the ability to play 96 / 192 files without (additional) filter function?
But once you apply your own DF function , why would you call it NOS in the first place, just because it has the ability to play 96 / 192 files without (additional) filter function?
Last edited:
Yet you said that any kind of masking technique, like filtering... is not good. So given that filtering is already being used when the recording is made, you'll still be hearing filtering when listening to NOS. That seems inescapable, given the format.
I am not disagreeing with what you hear, just your interpretation of what you hear (that filtering itself is somehow bad) doesn't make sense to me (yet). So I'd be inclined myself to look for other reasons why you don't like the sound of those commercial non-NOS designs.
I'm talking about the DA converters, not about the recording. The thing is that I like the natural sound of the TDA1541/A in NOS mode. I've tested it filtering with various DF, and AF, even adapting a Theta Gen V main bd (yes, with the Theta propietary filter) and finally, with tube output design, and some things more added, like a super clock, DJA, and so on, for me, it has better sound than any DF system. It is not as open as 2 mono dacs, but it is "live". The rest of the modern dacs are really good, but they are a little bit "artificial", like adding a little bit of sugar to an orange juice. I have musician friends, and all of them agree with me. And all of them have listened the same systems as me. And finally, what the soul&heart want is to immerse yourself in your own inner world and enjoy an unforgettable moment. That's all. But for doing this, first, you need to be able of forget the system sound, and for doing this, I can assure you that I need a natural reproduction system.
I think this discussion will end up nowhere. As I wrote earlier nobody is questioning the pro's and con's of any approach. These pro's and cons are well known.
It'll be IMO a matter of taste or rather greater tolerance against this or that flaw. There is no design ( I am aware of) without flaws.
Even Gordon Rankin/Wavelength Audio switched from NOS to Sabre this year. For sure the air for 15xx based devices gets thinner. 😉
On word about real musicians evaluating audio systems:
A real musician couldn't care less about a recording from a technical perspective. It'll never sound real. That's us who care!
My niece is a pianist. She finds an old Richter recording on Youtube more enjoyable on her LapTop, then a modern 5* Piano recording on my system.
( No. No. My system can't be that bad 😀 ).
A musicians brain is just differently programmed. They mostly focus on the performance and not on the SQ.
You might find that interwiew with Krystian Zimerman ( my favorite pianist) interesting. He outlines his opinion about modern digital recordings.
Cheers
It's great to see more folks offering their listening observations about John's SD player which he has worked so hard to perfect. Thank you Soundcheck for your opinion of the EC-Designs player compared to Touch+Buffalo. If you have a chance to hear John's ISD against other systems it would be great to hear a critique of his fully optimized system against another well regarding system. For a father of twin 2 year-olds who occasional find my stash of driver tubes I particularly find a one box solution appealing in this phase of life. If only the Euro would go to parity against the U.S. dollar !
It appears that this audio journey for the SD player is nearing its destination. John, why not place your 16/44 opinions "on the shelf" for a few months and focus your engineering talent on a modern 24/192 chipset and humor us all with your findings. I suspect this will be good for business too !!
It appears that this audio journey for the SD player is nearing its destination. John, why not place your 16/44 opinions "on the shelf" for a few months and focus your engineering talent on a modern 24/192 chipset and humor us all with your findings. I suspect this will be good for business too !!
Hi all,
After 4 years of intensive development I arrived at the final version, the (I)SD-player with TDA1541A-MK2 DAC module.
The early MK1 version still had some issues with DEM reclocking, buffering, clock distibution and output stage. All existing MK1 versions have recently been replaced with MK2 versions.
I aimed for most natural and realistic fully grain-free playback. This is not the same as impressive playback that creates an initial "wow" effect with "punch" and "air", followed by listening fatigue.
If connected equipment doesn't match digital audio source quality, differences between low and high resolution (not bit resolution!) sources will be barely audible and the conclusion could well be that there is no day and night difference.
Here is a list of things that I personally think are required for achieving most natural digital audio playback:
- No tampering with the original digital audio data (44.1 / 16) / bit-perfect source.
- Use of good digital recordings (there are day and night differences in recording quality).
- Clean (battery) power supplies.
- No switch-mode power supplies.
- No devices that radiate EMI (GSM, WLAN, DECT and so on) in the vicinity of the playback system.
- Cleanest possible digital audio source (extreme low jitter and noise levels).
- Masterclock as close as possible to both, DAC and digital audio source.
- One single ultra low jitter clock source to drive / synchronize the entire playback system.
- Straight-forward DAC chip without integrated digital filters and with pure constant current outputs.
- Simplest possible signal path with fewest possible components.
- No digital nor analogue filtering.
- I2S interface for real-time data transmission between digital audio source and DAC chip.
- No SPDIF or real-time USB digital audio interfaces.
- No OP-amps in the playback signal path.
- Correct impedance matching between audio components.
- No digital (switch-mode) power amplifiers in the playback signal path when using NOS.
- No global feedback in the playback signal path.
- Use of suitable power amplifier capable of high resolution playback
- Use of speakers capable of high resolution playback.
- Elimination of all ground loops.
Regarding 192 / 24 playback, the vast majority of albums is available on 44.1 / 16 only. I personally think that this offers more than enough resolution for audiophile playback when implemented correctly. Other problem is that all modern DACs are constructed in such way that natural sound reproduction is no longer possible. Finally we would require vanishing low jitter levels below 10 Femto seconds rms (10 Hz and up). I already had to go to extremes in order to achieve low enough jitter levels for 44.1 / 16 NOS playback.
After 4 years of intensive development I arrived at the final version, the (I)SD-player with TDA1541A-MK2 DAC module.
The early MK1 version still had some issues with DEM reclocking, buffering, clock distibution and output stage. All existing MK1 versions have recently been replaced with MK2 versions.
I aimed for most natural and realistic fully grain-free playback. This is not the same as impressive playback that creates an initial "wow" effect with "punch" and "air", followed by listening fatigue.
If connected equipment doesn't match digital audio source quality, differences between low and high resolution (not bit resolution!) sources will be barely audible and the conclusion could well be that there is no day and night difference.
Here is a list of things that I personally think are required for achieving most natural digital audio playback:
- No tampering with the original digital audio data (44.1 / 16) / bit-perfect source.
- Use of good digital recordings (there are day and night differences in recording quality).
- Clean (battery) power supplies.
- No switch-mode power supplies.
- No devices that radiate EMI (GSM, WLAN, DECT and so on) in the vicinity of the playback system.
- Cleanest possible digital audio source (extreme low jitter and noise levels).
- Masterclock as close as possible to both, DAC and digital audio source.
- One single ultra low jitter clock source to drive / synchronize the entire playback system.
- Straight-forward DAC chip without integrated digital filters and with pure constant current outputs.
- Simplest possible signal path with fewest possible components.
- No digital nor analogue filtering.
- I2S interface for real-time data transmission between digital audio source and DAC chip.
- No SPDIF or real-time USB digital audio interfaces.
- No OP-amps in the playback signal path.
- Correct impedance matching between audio components.
- No digital (switch-mode) power amplifiers in the playback signal path when using NOS.
- No global feedback in the playback signal path.
- Use of suitable power amplifier capable of high resolution playback
- Use of speakers capable of high resolution playback.
- Elimination of all ground loops.
Regarding 192 / 24 playback, the vast majority of albums is available on 44.1 / 16 only. I personally think that this offers more than enough resolution for audiophile playback when implemented correctly. Other problem is that all modern DACs are constructed in such way that natural sound reproduction is no longer possible. Finally we would require vanishing low jitter levels below 10 Femto seconds rms (10 Hz and up). I already had to go to extremes in order to achieve low enough jitter levels for 44.1 / 16 NOS playback.
Thank you -EC- for devoting to this enormous task. 🙂
At last one post about the thread subject and not about the superiority of OS over NOS! 😡
Cheers,
M.
At last one post about the thread subject and not about the superiority of OS over NOS! 😡
Cheers,
M.
> Most of the onno classics tracks won't play on the SD-player, this is probably caused by incorrect file headers. The SD-player checks these headers and if contained information is incorrect it skips the file.
I finally got round to trying the Onno recordings on "the other" SD players.
The QA550, e.g. plays them without problem. There is a slight "pop" when changing tracks, probably due to the reason you mentioned, but I can play ALL of the recordings listed on the website.
Since the other SD players use the standard PIC file handling routines, I tend to conclude that you might have some re-programming work to do.
Regards,
Patrick
I finally got round to trying the Onno recordings on "the other" SD players.
The QA550, e.g. plays them without problem. There is a slight "pop" when changing tracks, probably due to the reason you mentioned, but I can play ALL of the recordings listed on the website.
Since the other SD players use the standard PIC file handling routines, I tend to conclude that you might have some re-programming work to do.
Regards,
Patrick
Hi EUVL,
My brother improved the Microchip FAT libraries, removing a number of faults that are present in the original libraries. If other equipment uses these libraries without fixing these faults there could be problems. One of the many faults has to do with file names and special characters. So we basically use a customized FAT library for the SD-player.
The SD-transport is apparently the only device that actually detected that the file header was incorrect. Wat about the other devices? if these can't even detect a faulty file header, I have doubts about their reliability.
All I can say is that my brother is very strict in writing software and he has over 25 years of programming experience. He currently works as application programmer for Canon.
Onno's files work fine on the SD-transport after repairing the file headers.
My brother improved the Microchip FAT libraries, removing a number of faults that are present in the original libraries. If other equipment uses these libraries without fixing these faults there could be problems. One of the many faults has to do with file names and special characters. So we basically use a customized FAT library for the SD-player.
The SD-transport is apparently the only device that actually detected that the file header was incorrect. Wat about the other devices? if these can't even detect a faulty file header, I have doubts about their reliability.
All I can say is that my brother is very strict in writing software and he has over 25 years of programming experience. He currently works as application programmer for Canon.
Onno's files work fine on the SD-transport after repairing the file headers.
Congratulations John on completing the project to your high standards. It's also helpful that you list your "lessons learned" in the above post. I've always wanted to inquire about one of these:
- No devices that radiate EMI in the vicinity of the playback system
The processor in the SD player must radiate some EMI. From memory, the processor you use produces 40 MIPs. I have experience with a squeezebox II which I have modded following John Swenson's lead. In early experiments he cautioned against incorporating the SB unit inside the same box as a DIY Dac due to radiating EMI affecting the analog signal. In fact, even when placing the SB in close proximity to the audio system he measured radiating EMI which required shielding with aluminum or copper. Now the SB touch at 325 MIPs is a far larger processor than that which is used inside your SD Player at 40 MIPs.
Could you please describe any experimentation you underwent regarding this issue. Early on, did you experiment with placing the processor at different distances to the dac and analog circuitry? Did you experiment with shielding? Or is it that a 40 MIPs processor is so small not to be bothered with any type of intervention. I recollect that you do address noise induced jitter produced by the processor with your DJA circuit. Thank you for any comments.
- No devices that radiate EMI in the vicinity of the playback system
The processor in the SD player must radiate some EMI. From memory, the processor you use produces 40 MIPs. I have experience with a squeezebox II which I have modded following John Swenson's lead. In early experiments he cautioned against incorporating the SB unit inside the same box as a DIY Dac due to radiating EMI affecting the analog signal. In fact, even when placing the SB in close proximity to the audio system he measured radiating EMI which required shielding with aluminum or copper. Now the SB touch at 325 MIPs is a far larger processor than that which is used inside your SD Player at 40 MIPs.
Could you please describe any experimentation you underwent regarding this issue. Early on, did you experiment with placing the processor at different distances to the dac and analog circuitry? Did you experiment with shielding? Or is it that a 40 MIPs processor is so small not to be bothered with any type of intervention. I recollect that you do address noise induced jitter produced by the processor with your DJA circuit. Thank you for any comments.
Hi riotubes,
The SB processor load is way higher compared to the processor in the SD-transport.
The SD-transport uses DMA / hardware to generate the I2S stream, the processor is idling most of the time, it just reads some sectors from the SDHC card once in a while. My brother also spent a lot of time tweaking the already correct working software in order to achieve lowest possible interference levels.
The processor we used is based on nanowatt technology and it consumes less than 400 milliwatts in this application.
In the SD-player, ALL sub circuits run in sync with a single ultra low jitter 11.2896 MHz clock. This also helps to keep EMI levels down.
The SD-transport sits in a separate screened compartment (attached picture), and I used plenty of dissipative ferrite beads to prevent spreading of EMI. perfectionists could replace the 2mm thick aluminum SD-transport screen with a copper screen.
The picture shows the new TDA1541A-MK2 module.
The entire (I)SD player sits in a solid aluminum chassis with 3mm thick bottom and rear panel, and 8mm thick solid aluminum side panels. I placed a sheet of mica underneath the mains power supply PCB for optimal safety.
The DAC outputs on the MK2 module are placed as far away from the masterclock as possible in order to minimize crosstalk with the masterclock. The transformer is a toroidal version that has very low external electromagnetic field. Perfectionists could add an extra mu metal screen.
Very important feature of the SD-player is that it can run on battery power supply (3 x 12V battery) completely eliminating mains interference / ground loops.
The SB processor load is way higher compared to the processor in the SD-transport.
The SD-transport uses DMA / hardware to generate the I2S stream, the processor is idling most of the time, it just reads some sectors from the SDHC card once in a while. My brother also spent a lot of time tweaking the already correct working software in order to achieve lowest possible interference levels.
The processor we used is based on nanowatt technology and it consumes less than 400 milliwatts in this application.
In the SD-player, ALL sub circuits run in sync with a single ultra low jitter 11.2896 MHz clock. This also helps to keep EMI levels down.
The SD-transport sits in a separate screened compartment (attached picture), and I used plenty of dissipative ferrite beads to prevent spreading of EMI. perfectionists could replace the 2mm thick aluminum SD-transport screen with a copper screen.
The picture shows the new TDA1541A-MK2 module.
The entire (I)SD player sits in a solid aluminum chassis with 3mm thick bottom and rear panel, and 8mm thick solid aluminum side panels. I placed a sheet of mica underneath the mains power supply PCB for optimal safety.
The DAC outputs on the MK2 module are placed as far away from the masterclock as possible in order to minimize crosstalk with the masterclock. The transformer is a toroidal version that has very low external electromagnetic field. Perfectionists could add an extra mu metal screen.
Very important feature of the SD-player is that it can run on battery power supply (3 x 12V battery) completely eliminating mains interference / ground loops.
Attachments
onno records playing on the john's sd player
hi all,
i experienced the same problems playing the onno files directly on the sd-player due to the (incorrect?) headers. however, what i did is to make an audio-cd using ms-mediaplayer and converted the tracks back to wav-files with eac (exact audio copy) and finaly copied them into the sd.
i do not know if i have lost some quality that way, but the records are still very impresive 🙂
probably you can also use a virtual cd-drive and burn the files into an image-file and than convert them with eac into wav files. this might reduce the loss in quality if any.
cheers
mamal
hi all,
i experienced the same problems playing the onno files directly on the sd-player due to the (incorrect?) headers. however, what i did is to make an audio-cd using ms-mediaplayer and converted the tracks back to wav-files with eac (exact audio copy) and finaly copied them into the sd.
i do not know if i have lost some quality that way, but the records are still very impresive 🙂
probably you can also use a virtual cd-drive and burn the files into an image-file and than convert them with eac into wav files. this might reduce the loss in quality if any.
cheers
mamal
Hi mr_whocares,
File conversions from one lossless format to lossless format remain lossless. That's why these are called lossless formats. Theoretically you could perform many thousand subsequent file conversions (provided using lossles formats like WAV, APE, FLAC, Apple Lossless, and so on) without loosing a single bit of data.
By converting onno's files to another lossless format, only the file header is repaired, the actual digital audio data remains the same.
Still the lossless format chosen for real-time playback matters a lot. Losless compressed files like Apple Lossless Flac or APE require decoding during real-time playback. This puts a certain extra load on the processor (decoding). This increased processor load leads to increased interference / EMI levels. These in turn can affect jitter spectrum of the derived timing and data signals, I2S for example.
Therefore, WAV file format was chosen for the SD-player, this requires no conversion during playback and reduces processor load to almost zero as we can now use DMA / on-chip hardware only. This greatly reduces both jitter and EMI levels. This is one of the many subtle differences between the SD-transport and a QA550 for example.
With SPDIF / USB (isochronous) we have 64 bits / frame (for 16 ... 24 bit support). This means that a number of bits remain unused and are usually set to zero. Here an example for 16 bit / 64 bits / frame:
LLLLLLLLLLLLLLLL0000000000000000RRRRRRRRRRRRRRRR0000000000000000. L is left channel data, R is right channel data, 0 are unused bits.
Here for 24 bits / 64 bits / frame:
LLLLLLLLLLLLLLLLLLLLLLLL00000000RRRRRRRRRRRRRRRRRRRRRRRR00000000
So we end up with an unregular data flow, data bursts instead of a continuous data flow.
The SD-player uses 16 bits / 32 bits frame (like most 16 bit CD players):
LLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRR
Now we have an uninterrupted data flow, this also reduces interference. Other advantage is that we can use a lower bit clock 1.4112 Mhz instead of the usual 2.8224 MHz for 44.1 / 16 playback. This is also the lowest possible clock frequency for 44.1 / 16 I2S. Because I use a TDA1541A DAC, the highest clock frequency being fed into / used inside the DAC chip is the bit clock. By reducing its frequency I can reduce on-chip ground-bounce and related on-chip jitter. This is very important as DAC on-chip jitter is the largest additive jitter contributor.
File conversions from one lossless format to lossless format remain lossless. That's why these are called lossless formats. Theoretically you could perform many thousand subsequent file conversions (provided using lossles formats like WAV, APE, FLAC, Apple Lossless, and so on) without loosing a single bit of data.
By converting onno's files to another lossless format, only the file header is repaired, the actual digital audio data remains the same.
Still the lossless format chosen for real-time playback matters a lot. Losless compressed files like Apple Lossless Flac or APE require decoding during real-time playback. This puts a certain extra load on the processor (decoding). This increased processor load leads to increased interference / EMI levels. These in turn can affect jitter spectrum of the derived timing and data signals, I2S for example.
Therefore, WAV file format was chosen for the SD-player, this requires no conversion during playback and reduces processor load to almost zero as we can now use DMA / on-chip hardware only. This greatly reduces both jitter and EMI levels. This is one of the many subtle differences between the SD-transport and a QA550 for example.
With SPDIF / USB (isochronous) we have 64 bits / frame (for 16 ... 24 bit support). This means that a number of bits remain unused and are usually set to zero. Here an example for 16 bit / 64 bits / frame:
LLLLLLLLLLLLLLLL0000000000000000RRRRRRRRRRRRRRRR0000000000000000. L is left channel data, R is right channel data, 0 are unused bits.
Here for 24 bits / 64 bits / frame:
LLLLLLLLLLLLLLLLLLLLLLLL00000000RRRRRRRRRRRRRRRRRRRRRRRR00000000
So we end up with an unregular data flow, data bursts instead of a continuous data flow.
The SD-player uses 16 bits / 32 bits frame (like most 16 bit CD players):
LLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRR
Now we have an uninterrupted data flow, this also reduces interference. Other advantage is that we can use a lower bit clock 1.4112 Mhz instead of the usual 2.8224 MHz for 44.1 / 16 playback. This is also the lowest possible clock frequency for 44.1 / 16 I2S. Because I use a TDA1541A DAC, the highest clock frequency being fed into / used inside the DAC chip is the bit clock. By reducing its frequency I can reduce on-chip ground-bounce and related on-chip jitter. This is very important as DAC on-chip jitter is the largest additive jitter contributor.
"Repair": How do you know they are broken? What's supposed to be broken?
There are different .wav formats: .wav (MS Riff) and .wavpcm -- maybe that's the issue. But that wouldn't be a bug. That would be a limitation of your library not being able to read wavpcm.
If your player would skip the first 44 header bytes and not trying to get the infos from that header, those Onno files should play. Of course you wouldn't be able to validate the header information. If somebody would store a file with a different sample rate - you'd quickly hear it. 😉
If you really want to convert those files:
You could use a very simple Sox batch command on a Linux system on all of them to make them e.g. wav -- MS Riff format.
Code:
sox infile.wav -t wav outfile.wavas batch conversion - with a one-line command under Linux you could e.g. run in a terminal :
Code:
cd your-file-dir
ls *wav | while read "i" ; do sox "$i" -t wav "Si".new ; mv "$i".new "$i" ; done ;Here is some input about .wav from the sox man-pages:
Code:
.wav
Microsoft .WAV RIFF files. This is the native audio file format of Windows, and widely used for uncompressed audio.
Normally .wav files have all formatting information in their headers, and so do not need any format options specified for an input file. If
any are, they will override the file header, and you will be warned to this effect. You had better know what you are doing! Output format
options will cause a format conversion, and the .wav will written appropriately.
SoX can read and write PCM, μ-law, A-law, MS ADPCM, and IMA (or DVI) ADPCM. Big endian versions of RIFF files, called RIFX, are also sup‐
ported. To write a RIFX file, use the -B option with the output file options.
.wavpcm
A non-standard, but widely used, variant of .wav. Some applications cannot read a standard WAV file header for PCM-encoded data with sample-
size greater than 16-bits or with more than two channels, but can read a non-standard WAV header. It is likely that such applications will
eventually be updated to support the standard header, but in the mean time, this SoX format can be used to create files with the non-standard
header that should work with these applications. (Note that SoX will automatically detect and read WAV files with the non-standard header.)Cheers
Last edited:
Thanks Soundcheck, John.
One of the drawbacks of this approach is the cost of the SD cards. Another is the use of the SD card (for dumbs like yours truly). For the first problem, I am analysing the offers of the big retailers/producers, which have minimal orders of 50 (or higher) cards, but whose prices are interesting 😉
Sounds like a suitable project for group buy, doesn't it?
Dear John, I saw your nice and clean photo of the SD card player. Can you talk about the grounding?
Apart, I visited your site and I saw that you have only TDA1541 projects now...did you abandon TDA1543 project?
I am confident that you will still support the TDA1543 fans 😀
I don't know if you follow the Cup, but good luck today. 🙂
Best wishes to all.
M.
One of the drawbacks of this approach is the cost of the SD cards. Another is the use of the SD card (for dumbs like yours truly). For the first problem, I am analysing the offers of the big retailers/producers, which have minimal orders of 50 (or higher) cards, but whose prices are interesting 😉
Sounds like a suitable project for group buy, doesn't it?
Dear John, I saw your nice and clean photo of the SD card player. Can you talk about the grounding?
Apart, I visited your site and I saw that you have only TDA1541 projects now...did you abandon TDA1543 project?
I am confident that you will still support the TDA1543 fans 😀
I don't know if you follow the Cup, but good luck today. 🙂
Best wishes to all.
M.
Hi soundcheck,
The SD-player supports canonical WAV format only. This format works on all CD players.
This canonical or basic WAV format is derived from the over-complicated and poorly defined RIFF format.
Onno's files are of the RIFF format and don't start with audio data on position 40 as with the canonical WAV format. Instead they contain non-audio information specified with "pad".
So our player doesn't detect the expected file length at positions 40 ... 43, only zeroes. So it skips the file as detected file size is zero.
What's actually repaired is removing the data container (in this case identified as "pad") that starts at position 40 and contains non-audio data.
First of all the SD-player needs to know the exact file size prior to starting playback. This is required because we run the device using DMA / hardware mode. Unlike other players we try to minimize processor load to keep interference / EMI levels down.
The player would interpret non-audio data in the container starting at position 40 as being audio data, depending on the content of this container this could result in loud random noise, pops and clicks.
The majority of people who would use a SD-player are no system programmers, they probably couldn't get Linux up and running, let alone processing batch commands or use a terminal.
My brother plans to simply modify the ECDSD program so RIFF format is always converted to canonical WAV format. This way no programming skills are required.
The SD-player supports canonical WAV format only. This format works on all CD players.
This canonical or basic WAV format is derived from the over-complicated and poorly defined RIFF format.
Onno's files are of the RIFF format and don't start with audio data on position 40 as with the canonical WAV format. Instead they contain non-audio information specified with "pad".
So our player doesn't detect the expected file length at positions 40 ... 43, only zeroes. So it skips the file as detected file size is zero.
What's actually repaired is removing the data container (in this case identified as "pad") that starts at position 40 and contains non-audio data.
First of all the SD-player needs to know the exact file size prior to starting playback. This is required because we run the device using DMA / hardware mode. Unlike other players we try to minimize processor load to keep interference / EMI levels down.
The player would interpret non-audio data in the container starting at position 40 as being audio data, depending on the content of this container this could result in loud random noise, pops and clicks.
The majority of people who would use a SD-player are no system programmers, they probably couldn't get Linux up and running, let alone processing batch commands or use a terminal.
My brother plans to simply modify the ECDSD program so RIFF format is always converted to canonical WAV format. This way no programming skills are required.
Here is some extra information about WAVE format:
https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
Hi maxlorenz,
Cheaper low capacity cards can be used, 4Gb cards for example, these can still hold up to 6 CDs.
When you use iTunes or Rythmbox player, you can simply compile a play list of the music you plan to listen to that day or evening, and re-write the card every day. My brother specially wrote the free ECDSD software for this purpose.
One can buy a Kingstion 32Gb speed rating 4 card for around eur 75 each. This card can store approx. 54 CDs. In order to visualize how much this actually is, I attached a picture to illustrate this.
One doesn't realize this when looking at the tiny SD-player, but it's actually an audiophile Jukebox. The SD-player supports random disc / track play for plenty of variation during listening.
The SD-player is a double insulated device (no earth connection). The entire housing is a massive star ground (GND) and shielding. The TDA1541A-MK2 DAC module is grounded on 4 points, massive 3mm thick sheet of aluminum provides extra low impedance bypass and shields the electronics on the solder side.
When battery powered, it's a "floating" device that completely eliminates ground loops running through the sensitive DAC electronics.
The ISD player also uses the complete massive aluminum chassis as star ground / reference. Like the SD-player, the SD-player part of the ISD-player can be fully battery powered if desired.
Although the TDA1543 MK2 module has a "magical" sound as a customer described it, it lacks some detail and dynamics for obvious reasons. Since I only want to offer the best, I removed this module from my website.
People can email me if they are still interested in these TDA1543-MK2 modules.
The Dutch part of me will cheer when Holland wins 🙂
Cheaper low capacity cards can be used, 4Gb cards for example, these can still hold up to 6 CDs.
When you use iTunes or Rythmbox player, you can simply compile a play list of the music you plan to listen to that day or evening, and re-write the card every day. My brother specially wrote the free ECDSD software for this purpose.
One can buy a Kingstion 32Gb speed rating 4 card for around eur 75 each. This card can store approx. 54 CDs. In order to visualize how much this actually is, I attached a picture to illustrate this.
One doesn't realize this when looking at the tiny SD-player, but it's actually an audiophile Jukebox. The SD-player supports random disc / track play for plenty of variation during listening.
The SD-player is a double insulated device (no earth connection). The entire housing is a massive star ground (GND) and shielding. The TDA1541A-MK2 DAC module is grounded on 4 points, massive 3mm thick sheet of aluminum provides extra low impedance bypass and shields the electronics on the solder side.
When battery powered, it's a "floating" device that completely eliminates ground loops running through the sensitive DAC electronics.
The ISD player also uses the complete massive aluminum chassis as star ground / reference. Like the SD-player, the SD-player part of the ISD-player can be fully battery powered if desired.
Although the TDA1543 MK2 module has a "magical" sound as a customer described it, it lacks some detail and dynamics for obvious reasons. Since I only want to offer the best, I removed this module from my website.
People can email me if they are still interested in these TDA1543-MK2 modules.
The Dutch part of me will cheer when Holland wins 🙂
Attachments
Did you have a look at the spec by yourself? I did.
Even there they refer to Sox. 😉 Canonical is the same as the wav format I refered to earlier..
Byte 0-43 are header related. That's what I am saying. No idea what you're referring to. Where do you see "40" bytes? 😕
But obviously that's not your issue.
You need to extract header information to get your player going. Different .wav formats will just not work. There is nothing wrong with it.
I guess Onno is using wavpcm, which is normally used in the recording scene. ( Though I havn't looked into it.)
Cheers
- Status
- Not open for further replies.