Tír Na HiFi

Ken Moreland wrote:3.72 is excellent but doesn't play 24/96 just a blast of noise, great for getting me out of the chair.
KM

Indeed, with me as well.
I noticed 3.70 does this as well but only after a while.
3.72 gets you moving immediately :-)

Aleg wrote:

Ken Moreland wrote:3.72 is excellent but doesn't play 24/96 just a blast of noise, great for getting me out of the chair.
KM

Indeed, with me as well.
I noticed 3.70 does this as well but only after a while.
3.72 gets you moving immediately :-)

+1
Excellent work, Gordon!

sbgk wrote:uploaded 3.72, a setting wasn't correct.

3.92 with 8.91 Normal sounds excellent. But MQnplay.exe is still taking 200-300KB RAM after the track ends.

sbgk wrote:Taggart, Is your software affected by this ?

"I found very important clause in the release notes of LibFLAC 1.3.1 it seems there is
security vulnerability fix. the bug existed on LibFLAC 1.3.0 or earlier version is fixed on LibFLAC 1.3.1.

this security vulnerability is typical buffer overflow and
this bug enables for attacker to execute arbitrary program code

if your program statically links LibFLAC code, your program must rebuild using newer LibFLAC"

Thanks, Gordon for the information.
But I think not. Mqnload uses flac.exe and not libFLAC. Even if this security vulnerability exists also in flac.exe versions prior to 1.3.1 the risk might be very limited, because most of our Audio PC aren't connected to the Internet and except audio relevant programs not much other software should be installed. Though, an update to actual version 1.3.1 of flac.exe is always advisable - at least because of performance improvements.

Thanks for your constant development on MQn!

BTW Thomas - so when 2012 sits in RAM disk your music of course is still loaded from physical SSD / HDD?

sebna wrote:BTW Thomas - so when 2012 sits in RAM disk your music of course is still loaded from physical SSD / HDD?

I have tested all versions. As mentioned I am very carefull if it comes to talk about sq. My setup.., my ears.., my brain ;) ....

We try to measure the difference we hear, but we are at the start. A slight but recognizable added clearness if you play the same track (.wav 1644) from RAM disk instead of SSD. Very quiet chimes in the backgound could be recognized per single hit of the chime.

Yes, both versions are loaded by MQn into RAM, but from OS into RAM is much faster than from SSD into RAM. There is a difference, I try to understand to make use of it. If I am right, there has been the same discussion quite some time ago loading files from C:\ instead of HDD folder.

This seems to go along with Gordon's remark that the way how a file is stored changes something as well. I would like to understand how RAM is organized by the system. Might be that faster delivery makes bigger clusters possible which would mean less clusters per file?

Anyone any ideas?
Thomas

maybe the digital signal is being squashed or extended slightly so that the receivers electrical noise is affected eg frequency modulation or jitter if the signal is less consistent. So it's still bit perfect, but the ease with which the receiver identifies the bit changes with noise.

The things that affect the load sq are all things that increase noise, so removing them has worked.

see Meridian is proposing a new format

thinking about it the noise issue is worse when sending large volumes of data between devices, so a better way would be to send smaller volumes of data at higher frequency, is that what dsd is doing ?

think dsd can just increment a bit at a time.

a better way might have been to invert the signal so the loud parts are when there is no data and the quite parts are when there are full 16 bits (for 16/44.1) because loud parts have more frequency extremes and volume extremes.

The issue is how to describe the sound wave without having to send large amounts of data between devices.

sbgk wrote:see Meridian is proposing a new format

Yea, MQA. But if it sounds the same as 14/192 I don't really see the point even though it will take up less disk space/streaming bandwidth. If it sounds better then it will have some support directly correlated to how much better it sounds.

thinking about it the noise issue is worse when sending large volumes of data between devices, so a better way would be to send smaller volumes of data at higher frequency, is that what dsd is doing ?

think dsd can just increment a bit at a time.

It may be to do with the processing load & it's effect on the PS noise i.e. bigger data chunks in bursts will cause a big draw on the PS every time a burst of data arrives - so we have a situation where the PS noise increases in bursts (unless you have a rock steady PS). Smaller data chunks transmitted more often results in a more steady load on the PS so steadier PS noise i.e less noise fluctuation. I imagine PS noise fluctuation might be at the heart of this?

DSD also has zero processing required to convert to analogue - just a low pass filter will do i.e passive devices which don't have any PS current draws.

How did your experiments with optimising WAV file loading into RAM?

jkeny wrote:

sbgk wrote:see Meridian is proposing a new format

Yea, MQA. But if it sounds the same as 14/192 I don't really see the point even though it will take up less disk space/streaming bandwidth. If it sounds better then it will have some support directly correlated to how much better it sounds.

thinking about it the noise issue is worse when sending large volumes of data between devices, so a better way would be to send smaller volumes of data at higher frequency, is that what dsd is doing ?

think dsd can just increment a bit at a time.

It may be to do with the processing load & it's effect on the PS noise i.e. bigger data chunks in bursts will cause a big draw on the PS every time a burst of data arrives - so we have a situation where the PS noise increases in bursts (unless you have a rock steady PS). Smaller data chunks transmitted more often results in a more steady load on the PS so steadier PS noise i.e less noise fluctuation. I imagine PS noise fluctuation might be at the heart of this?

DSD also has zero processing required to convert to analogue - just a low pass filter will do i.e passive devices which don't have any PS current draws.

How did your experiments with optimising WAV file loading into RAM?

so we have to wait for optical chips, who said digital audio was easy.

people seem to notice a difference with the different versions of control that have been released, so that tends to indicate the loading of data into ram has an effect on the final sq. Am trying to get control at the same level as play which is tricky. I think the new control versions are giving a more detailed, less digital sound.