Tír Na HiFi

jkeny wrote:Lekt, I startred a thread on an I2S error which afflicts all DACs & which is solvable in software viewtopic.php?f=15&t=2485

I thought you might be interested in trying an implementation of it in your player to check what it sounds like?
PM or post if you want to follow it up

Thanks jkeny for recommend to this problem. I have read your overview. It's intersting, only for who having good and high mathematical skill, of course not easy. Curently lekt player don't play with 24/96000 and 24/192000, this task in my plan. so too busy with 16/44100 in 16 bit container, will try with 24 bit.
Best Regards.

lekt wrote:

jkeny wrote:Lekt, I startred a thread on an I2S error which afflicts all DACs & which is solvable in software viewtopic.php?f=15&t=2485

I thought you might be interested in trying an implementation of it in your player to check what it sounds like?
PM or post if you want to follow it up

Thanks jkeny for recommend to this problem. I have read your overview. It's intersting, only for who having good and high mathematical skill, of course not easy. Curently lekt player don't play with 24/96000 and 24/192000, this task in my plan. so too busy with 16/44100 in 16 bit container, will try with 24 bit.
Best Regards.

Don't worry about the maths, it's not difficult at all
The thing is, I don't know if 16bit in 16bit container isn't padded out to 24bit in the DAC - I suspect it is & therefore this will be done wrong. As I suggested to Gordon, pre-pad correctly all 16bit files to 24 bit will overcome this & set-up your player for handling 24bit anyway.

jkeny wrote:Don't worry about the maths, it's not difficult at all
The thing is, I don't know if 16bit in 16bit container isn't padded out to 24bit in the DAC - I suspect it is & therefore this will be done wrong. As I suggested to Gordon, pre-pad correctly all 16bit files to 24 bit will overcome this & set-up your player for handling 24bit anyway.

I was confused, read from http://en.wikipedia.org/wiki/Two's_complement with many... things and think as I said. but it's not difficult at all, as you said. logical operators, >>, << are popular operators, think simple. but only most best method can be used for audio DSP (although here's not DSP, only pad zero bits, but it's processing), otherwise time of data loading into RAM will be longer. everything little work before render loop also affect to SQ.

jesuscheung wrote:hey goon-heaven, we are confused with the version number. 2.71 v2 is MQn. lekt's is 2.1.7.2... haha

interesting, similar.

lekt wrote:

jkeny wrote:Don't worry about the maths, it's not difficult at all
The thing is, I don't know if 16bit in 16bit container isn't padded out to 24bit in the DAC - I suspect it is & therefore this will be done wrong. As I suggested to Gordon, pre-pad correctly all 16bit files to 24 bit will overcome this & set-up your player for handling 24bit anyway.

I was confused, read from http://en.wikipedia.org/wiki/Two's_complement with many... things and think as I said. but it's not difficult at all, as you said.

Yes, the only part of the wiki that is relevant is the first line in the SIgn Extension section

"When turning a two's-complement number with a certain number of bits into one with more bits (e.g., when copying from a 1 byte variable to a two byte variable), the most-significant bit must be repeated in all the extra bits and lower bits.
Some processors have instructions to do this in a single instruction. On other processors a conditional must be used followed with code to set the relevant bits or bytes."

logical operators, >>, << are popular operators, think simple. but only most best method can be used for audio DSP (although here's not DSP, only pad zero bits, but it's processing), otherwise time of data loading into RAM will be longer. everything little work before render loop also affect to SQ.

Yes there is some processing hit from the extra instruction & this MAY effect SQ but leaving it out DEFINITELY affects SQ to the level of 1 LSB - in other words it will be more significant at quiet sounds or at note fades.

BTW, this is called a "packed move with extend" in Intel operators here http://software.intel.com/en-us/node/461924

BTW, BTW sections 1.2.8 in this document - about packing for DMA efficiency (& sign extension :)) should also be of interest http://www.ti.com/lit/ug/sprufx4a/sprufx4a.pdf

guys, as a quick possible solution, if 16 in 24bits container is a problem, try install reclock to reclock 16 to 24, and see if lekt player works. also make sure the buffer size matches exactly as it is on your DAC.

worth a try.

lekt, possible to make a version that ignores all soundstage, earaches everything. just focus on most vibration+best drum?

interested to know what is maximum possible.

jesuscheung wrote:lekt, possible to make a version that ignores all soundstage, earaches everything. just focus on most vibration+best drum?

interested to know what is maximum possible.

"most vibration+best drum" can get only soundstage is enough, otherwise vibration is "like as vibration", not good, noisy (in this case drum sound will be dumb, not enough space for its echo (need a bit of bit echo, much echo is bad).
i found out new good method, doing new version, wait for me, soon.

uploaded v2.18 1024, v2.18.1 1024, v2.18.2 1024

better and more correct vibration, more sounds density. try these for piano

lekt wrote:uploaded v2.18 1024, v2.18.1 1024, v2.18.2 1024

better and more correct vibration, more sounds density. try these for piano

2.18 works.
2.18.1 stuck no sound. 2.18.2 also stuck no sound.

-5 seconds first impression already better!

piano. much better.
-bass notes sound quite perfect.
-treble notes are improving, but are still a bit bright. the heavier are the treble notes, the less the vibration and the more bright it becomes. i still have ear pain on heavy/loud treble notes on headphones. speakers ok.
-overall: crispier, flows better.

will test more.