MQN

[LowOrbit]

Don't you think details and 'harshness' may always go together?

I mean might increased details be interpreted as harshness, without actually being harshness?

I find this is the tradeoff, especially where female vocal is concerned. It's as though the extra detail moves the mic closer to the vocalist. When sibilance becomes unnatural it destroys my emotional connection as it's pretty much all I can then hear.

I know what you mean, but I think the sibiliance is part of the noise, not the recording. I spent many years recording voices in some of the top commercial recording studios in London and sibiliance was never a problem in the recording process. If you get a sufficiently clean replay the sibiliance disappears.

[Clive]

Don't you think details and 'harshness' may always go together?

I mean might increased details be interpreted as harshness, without actually being harshness?

I find this is the tradeoff, especially where female vocal is concerned. It's as though the extra detail moves the mic closer to the vocalist. When sibilance becomes unnatural it destroys my emotional connection as it's pretty much all I can then hear.

I know what you mean, but I think the sibiliance is part of the noise, not the recording. I spent many years recording voices in some of the top commercial recording studios in London and sibiliance was never a problem in the recording process. If you get a sufficiently clean replay the sibiliance disappears.

Excellent, I can live with this explanation as it gives hope that we can have detail that's free of unnatural sibilance.

[sbgk]

Don't you think details and 'harshness' may always go together?

I mean might increased details be interpreted as harshness, without actually being harshness?

I find this is the tradeoff, especially where female vocal is concerned. It's as though the extra detail moves the mic closer to the vocalist. When sibilance becomes unnatural it destroys my emotional connection as it's pretty much all I can then hear.

from reading the memory doc I linked to previously, it looks like large memory pages is going to be a big benefit, so I should concentrate on getting that done.

Shall do a 24 bit version and then work on the large memory page version.

There is no guarantee that a good sound can be obtained from a cpu transfer, maybe would be best done on dedicated chips close to the destination. Part of the problem is that we are just not transferring enough data, so the fast methods have a start up cost which may outweigh the benefits when applied to 8 kb. What is clear is that noise is produced when transferring through the cpu and this noise affects the SQ. So far I have been trying to transfer the maximum amount in the shortest time, maybe I should look at the opposite and see if the noise is less or of a different quality.

[Clive101]

Shall do a 24 bit version and then work on the large memory page version.

Hi sbgk

I would love a 24 bit version please - I tried a test one that played 24 bit files (with great results) but haven't been able to try 16 bit // 44 Khz -so 24 bit would be very welcome!

Regards
Clive

[jesuscheung]

JC

do you think we require more bass?

what do you think the best complete version is?

still waiting for a version that is focus, mellow, emotional at no expense of micro-details. so far, mellow eats away micro-details. the most revealing versions add hardness. waiting for this pattern to break! and then the best version will come.

JC

Don't you think details and 'harshness' may always go together?

I mean might increased details be interpreted as harshness, without actually being harshness?

I once had a 'discussion' with Mark Waldrep, dr. Aix from Aix Records about this, and we both agreed that it might be possible that increased details, that also can come about in HighRes music, might be felt/interpreted as increased harshness, being sharp edged or be 'digital' sounding. While it is 'just' increased levels of detail of smaller movements, of sharper transients being audible.

What's your view on this?

Cheers

Aleg

seems like you are talking about harshness created from overly-revealing or too much details.

don't think the current most revealing version of MQn is overly-revealing at all. those harshness are slowly going away with newer versions.

[jrling]

What is clear is that noise is produced when transferring through the cpu and this noise affects the SQ. So far I have been trying to transfer the maximum amount in the shortest time, maybe I should look at the opposite and see if the noise is less or of a different quality.

SBGK - I was thinking the same conceptually. Got to be worth a little of your valuable time I would humbly suggest.
The current route has produced unbelievably good results, but I would think the law of diminishing returns is kicking in?

Also, although may be wrong, I read of users who under clock their CPU and RAM claiming benefits in SQ, which could support your latest hunch.

Jonathan

[taggart]

Taggart
The bits aren't important because they are the same, but the difference in processing required is what is the significant factor in these sound quality differences. That's also where players like MQn and JPlay find their improvements.

Cheers

Aleg

Aleg, yes you are right, players are better or worse because of their different software techniques and their processing. We've learned this lesson with JPLAY and now again with MQn. But don't you think that bit-identical files should sound the same, if same system and same player software is used? I don't see any logical explanation of how bit-identical files could reflect their different creation processes. Because the information they contain is identical. This is my personal view, but if you have an explanation, I'm all ears.

[LowOrbit]

Taggart
The bits aren't important because they are the same, but the difference in processing required is what is the significant factor in these sound quality differences. That's also where players like MQn and JPlay find their improvements.

Cheers

Aleg

Aleg, yes you are right, players are better or worse because of their different software techniques and their processing. We've learned this lesson with JPLAY and now again with MQn. But don't you think that bit-identical files should sound the same, if same system and same player software is used? I don't see any logical explanation of how bit-identical files could reflect their different creation processes. Because the information they contain is identical. This is my personal view, but if you have an explanation, I'm all ears.

Hi Taggart

You are making a valid point. My only concern would be that maybe not all conversion algorithms from one format to the other are perfect or equal. Offline, non-realtime conversion should create equal results in different players if the conversion is done properly. Realtime is a bit more of a lottery due to the many other processes sharing cpu time.

[sbgk]

You are making a valid point. My only concern would be that maybe not all conversion algorithms from one format to the other are perfect or equal. Offline, non-realtime conversion should create equal results in different players if the conversion is done properly. Realtime is a bit more of a lottery due to the many other processes sharing cpu time.

In MQn the conversion is done before play starts. Even if realtime I think the conversion is still perfect (flac->wav/pcm, just that the additional load on the cpu has a negative effect on SQ.

[Clive101]

As the OS seems to be so important (or perhaps minimising the CPU load etc by optimising the environment, ie less processes running etc) what about trying something like Windows Embedded 8.1 or even trying a very simple WAV - PCM player on a completely stripped down Linux system - I would have thought it would be much easier to get optimal "Bits" to a DAC in perfect timing / uncorrupted by noise etc with less other software competing for the CPU.

If all testing suggests that more CPU cycles equal more noise and deteriorates sound quality then wouldn't it follow that Windows just isn't going to be the best OS?

Just a thought
Clive