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
Maplin XM21X 12V float charging A123 26650 LiFePO4 battery/Maxwell Supercap PSU for Mitac PD10-BI J1900 Bay Trail, WTFPlay, Hiface Evo, Bow Technologies 1704 NOS DAC, StereoKnight TVC, Quad II monoblocks, ZU Audio Druid Mk4/Method Sub
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
Coax tractrix horn system 2 corner subwoofer / 6 full digital amplifier D802 floating PSU 12V battery / digital XO/DRC / 2 PC floating PSU picoless battery/Mutec REF 10/2x Mutec MC3.1+ USB floating PSU 6V/FireFace UCX floating PSU 12V battery/Mutec MC-4
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.
Gigabyte H97M-D3H with PPA OCXO module. i7-4790T, 800MHz. 8GB Ram, 800MHz.
PPA 2-rail LPSU & Pico. JCAT battery for OS-SSD and PPA v3 USBcard.
Server 2012 R2, AO 1.40. APL HiFi DAC-S, upd. Only use 1644 .wav
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.
Coax tractrix horn system 2 corner subwoofer / 6 full digital amplifier D802 floating PSU 12V battery / digital XO/DRC / 2 PC floating PSU picoless battery/Mutec REF 10/2x Mutec MC3.1+ USB floating PSU 6V/FireFace UCX floating PSU 12V battery/Mutec MC-4
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.
"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"