Cobra,
It would be great if one could switch out the DF 1704 to a nice one from npc or even pacific microsonics. Both of these are as far as I understand better then the DF1704 at handling bit depht changes.
If these chips were in this dac one could leave the 8420 as is and just change the inputformat on the filter to handle different source material.
This SM5847 exists but can not easily be changed for the df1704.
It would be great if one could switch out the DF 1704 to a nice one from npc or even pacific microsonics. Both of these are as far as I understand better then the DF1704 at handling bit depht changes.
If these chips were in this dac one could leave the 8420 as is and just change the inputformat on the filter to handle different source material.
This SM5847 exists but can not easily be changed for the df1704.
A 8,
I don't think anything I could possibly suggest would help in this situation. I simply do not see where quantisation noise, scaling or dither apply. It seems the CS8420 "hardware mode glitch" referred to in a previous thread is far more likely. It also
seems likely that if the CS8420 does not like 16 bit inputs, simply relocating it is unlikely to change that.
I am not being evasive or intentionally unhelpful but anything I suggest would be based on how I perceive things to be, and that it would appear is contrary to how you seem to see things.
ray.
I don't think anything I could possibly suggest would help in this situation. I simply do not see where quantisation noise, scaling or dither apply. It seems the CS8420 "hardware mode glitch" referred to in a previous thread is far more likely. It also
seems likely that if the CS8420 does not like 16 bit inputs, simply relocating it is unlikely to change that.
I am not being evasive or intentionally unhelpful but anything I suggest would be based on how I perceive things to be, and that it would appear is contrary to how you seem to see things.
ray.
rfbrw,
I was mot trying to trick you into a debate, I am sincerely interested in how I could define the last 8 bits without adding _another_ 8420.
The 8420 do not like 16 bit input when it has no way of knowing when its 16 or 24, it will deal with 16 bits if its set up to do so (which was what I eventually did by adding another one in the cdp)
It's spelled out pretty clear in the data sheet, page 15 chapter 5.1.
This is not a very good solution as you initially indicated however it was the only one I could come up with.
Don't get me wrong here, I would also prefer a 16 bit dac if cd was the only source feeding it and I agree I general that round off, dither and truncation is a bad thing.
You do seem to understand these issues better then I and I think some of us would really appreciate any ideas that will help manage this issue...
I was mot trying to trick you into a debate, I am sincerely interested in how I could define the last 8 bits without adding _another_ 8420.
The 8420 do not like 16 bit input when it has no way of knowing when its 16 or 24, it will deal with 16 bits if its set up to do so (which was what I eventually did by adding another one in the cdp)
It's spelled out pretty clear in the data sheet, page 15 chapter 5.1.
This is not a very good solution as you initially indicated however it was the only one I could come up with.
Don't get me wrong here, I would also prefer a 16 bit dac if cd was the only source feeding it and I agree I general that round off, dither and truncation is a bad thing.
You do seem to understand these issues better then I and I think some of us would really appreciate any ideas that will help manage this issue...
A 8 said:
Though many will disagree and disagree in the extreme have you considered the possibility that having two ASRC's in series and the extra processing is a good thing ? Anyway if you wish to minimise the amount of processing, I would start by finding the source of serial data in the CDP and whether the format can be changed to feed the AES tx LSB justified 16 bit data.
ray.
The CS8420 will treat all inputs as 24 bits, if it only gets 16 then the last eight will be set to zero. This is just fine assuming the 16bits that come off the CD have been properly dithered, which they should be.
The output word length of the CS8420 in my DAC is set to 24 bits any trunction here is dithered in the CS8420.
It has been suggested to me that the SRC in the CS8420 isn't that great but I haven't tried it with the SRC disabled. Also note that without the SRC the clock is recovered from the SPDIF input and the oscillator is no longer used.
Finally with proper dither on the recording end of the chain it is possible to encode information below the least significant bit. This is reproduced when the data is lowpass filtered (averaged) on the playback end. Thus with an oversampling filter it is a good idea to use DAC chips greater than 16bits.
The output word length of the CS8420 in my DAC is set to 24 bits any trunction here is dithered in the CS8420.
It has been suggested to me that the SRC in the CS8420 isn't that great but I haven't tried it with the SRC disabled. Also note that without the SRC the clock is recovered from the SPDIF input and the oscillator is no longer used.
Finally with proper dither on the recording end of the chain it is possible to encode information below the least significant bit. This is reproduced when the data is lowpass filtered (averaged) on the playback end. Thus with an oversampling filter it is a good idea to use DAC chips greater than 16bits.
That's right, the dithering should already have been done, in this case it will have been done when the CD was made.
In right justified mode you need to tell it the number of bits simply because of the way the data is framed within the word clock.
AFAIK SPDIF will assume 24 bit and work the same as I2S and left justified as pointed out by rfbrw.
rfbrw,
Not really, I've just viewed it as an unwanted extra processing stage to get 24 bit data for the broadhurst based dac to work with.
However as I stated earlier in my set up it does significantly improve the sonics of the dac.
Perhaps it could have some form of averaging effect?
Just to avoid any confusion.
What I've done was lifting off the 16 bit serial data out of the cdp, fed a 8420 16 bit serial in and AES out. This puts the 8420 in a situation where it creates 24 bit data.
The first src's 24 bit data then feeds the second 8420 AES 24 bit input and gets another sample rate conversion and final processing.
Am I reading you correct in that you are suggesting just switching the 8420 in the cdp for a AES TX that will add zeros up to 24 bits?
Thx.
Not really, I've just viewed it as an unwanted extra processing stage to get 24 bit data for the broadhurst based dac to work with.
However as I stated earlier in my set up it does significantly improve the sonics of the dac.
Perhaps it could have some form of averaging effect?
Just to avoid any confusion.
What I've done was lifting off the 16 bit serial data out of the cdp, fed a 8420 16 bit serial in and AES out. This puts the 8420 in a situation where it creates 24 bit data.
The first src's 24 bit data then feeds the second 8420 AES 24 bit input and gets another sample rate conversion and final processing.
Am I reading you correct in that you are suggesting just switching the 8420 in the cdp for a AES TX that will add zeros up to 24 bits?
Thx.
Dave,
You need 24 bit native, dithered or zero padded data for the 8420 as implemented in the broadhurst dac to perform at its best.
This is not available from your cd or average cdp.
Cd's gets dither treatment when the data is bit and rate converted during the mastering process ie from 20, 24 48/96 to 16/44.
BTW, When fed nice 24 bit native data I think its great.
You need 24 bit native, dithered or zero padded data for the 8420 as implemented in the broadhurst dac to perform at its best.
This is not available from your cd or average cdp.
Cd's gets dither treatment when the data is bit and rate converted during the mastering process ie from 20, 24 48/96 to 16/44.
BTW, When fed nice 24 bit native data I think its great.
A 8 said:
I would look to do away with the extra processing and/or zero padding by making it possible to switch between the CS8420 in hardware mode 1 for 24bit sources and hardware mode 2 set to receive 16 bit LSB/right justified data from a second DIR for 16 bit sources. The second DIR would be set to output 16bit LSB/right justified data.
ray.
Guys
As I was about to do a little housekeeping and tidy the place up a bit by giving these off thread posts a new home where they can be discussed properly, I came across a problem... I haven't got a clue what you are talking about, so I can't give it an appropriate title!
So, tell me want you want this new thread to be called and I will set it up for you folks.
As I was about to do a little housekeeping and tidy the place up a bit by giving these off thread posts a new home where they can be discussed properly, I came across a problem... I haven't got a clue what you are talking about, so I can't give it an appropriate title!
So, tell me want you want this new thread to be called and I will set it up for you folks.
pinkmouse said:Guys
As I was about to do a little housekeeping and tidy the place up a bit by giving these off thread posts a new home where they can be discussed properly, I came across a problem... I haven't got a clue what you are talking about, so I can't give it an appropriate title!
So, tell me want you want this new thread to be called and I will set it up for you folks.
Probably a little late in the day for this but the OT's mainly revolved around the Broadhurst dac and its use of CS8420.
ray.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.