Page 625 of 804

Re: MQN

Posted: Sun Nov 30, 2014 9:14 pm
by jrling
sbgk wrote:
Fujak wrote:
Aleg wrote:mqncontrol 3.67 and 3.68 don't play on my setup

mqncontrol or 0 and 3.66 loose resolution compared to 3.64 and become a bit soggy in style.
same to me; mqncontrol 3.68 doesn't work. 3.64 with MQn 8.91 works an sounds very detailed.
3.68 does work, it doesn't play the first track, so need to select more than one track and then only the second onwards will play.

Shall fix today, but it's worth trying 3.68 - I think there is an improvement. This is all unexpected, the bits in ram are affected by the load process or rather the sound of the bits is affected.
Tried 3.68 Control with 8.91 Normal. Very good. Seems to have more detail but less harshness - which is a good result.

Some issues -

1. I get a click right at the start of every track (well not the first track because that does not play). Makes me a bit nervous with my sensitive speakers
2. After an hour's listening I got a track that stopped part way through.
3. Looked at Task Manager and saw that when a session ended but I did not press 'X' to close the window, the amount of RAM being used by mqnplay.exe was climbing at about 200-300kb per second! When I closed the MQnPlay.exe console window with 'X', the process disappeared (which one would expect).

Hope that helps.

Jonathan

Re: MQN

Posted: Sun Nov 30, 2014 11:13 pm
by Octagon
jrling wrote: 3. Looked at Task Manager and saw that when a session ended but I did not press 'X' to close the window, the amount of RAM being used by mqnplay.exe was climbing at about 200-300kb per second! When I closed the MQnPlay.exe console window with 'X', the process disappeared (which one...
+1

Re: MQN

Posted: Mon Dec 01, 2014 3:37 pm
by janh
3. Looked at Task Manager and saw that when a session ended but I did not press 'X' to close the window, the amount of RAM being used by mqnplay.exe was climbing at about 200-300kb per second! When I closed the MQnPlay.exe console window with 'X', the process disappeared
+1
- and it has been so for some time now, with control 3.64 and the later MQnplay Normal.
I use Win 8.1, 8GB Ram.
Only in the last weeks, a few times when I did not close the MQn-window after playing, I had sudden noise from the loudspeakers, and one time it was a bit nasty. This noise always came about two to three hours after end of playing. So now I take care to close the MQn window after listening.

Re: MQN

Posted: Tue Dec 02, 2014 11:16 pm
by sbgk
uploaded control 3.69 which has further optimisations, still has glitch at start which I'll get fixed.

3.70 fixes the glitch at the start.

Re: MQN

Posted: Wed Dec 03, 2014 5:54 pm
by janh
With Win 8.1 and Play 8.91 Normal,
Control 3.70 is a marked improvement over 3.64 . The sound is just more clear.

Re: MQN

Posted: Wed Dec 03, 2014 7:40 pm
by Octagon
3.70 offers great sq. As mentioned the glitch is away and also the growing RAM amount of play.exe is stopped after playing.
I recognize a gap of 15-18 seconds before playing starts. (edit)

The performance with OS in RAM is incredible, with MQn CPU usage is below 1% including online convolving via VSTHost. Compared to JPlay that is far less allthough JPlay is pretty well with 5% CPU usage including online convolving with foobar's fooconvolver. If one is interested I might post some screenshots from taskmanager.

Re: MQN

Posted: Thu Dec 04, 2014 9:16 am
by lukivision
Regarding SQ 3.70 is a step ahead, really. Is there a way, to use MQN as foobar´s sound engine? I can´t get it to work.

Luki

Re: MQN

Posted: Thu Dec 04, 2014 1:29 pm
by sbgk
lukivision wrote:Regarding SQ 3.70 is a step ahead, really. Is there a way, to use MQN as foobar´s sound engine? I can´t get it to work.

Luki
am further optimising control. Am also considering a wav file program to read in and optimally write an optimised wav file so it can be demonstrated on other players. Wonder if it would make a difference to other types of files eg jpg or raw files.

Re: MQN

Posted: Thu Dec 04, 2014 1:31 pm
by sbgk
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"

Re: MQN

Posted: Thu Dec 04, 2014 2:18 pm
by Octagon
sbgk wrote:Am also considering a wav file program to read in and optimally write an optimised wav file...
Is that the reason why 3.70 takes some seconds to start? Are you reorganizing the way of writing the music file into RAM?