Jump to content
IGNORED

J River to HQPlayer


Recommended Posts

8 hours ago, teodorom said:

C:\Program Files\Signalyst\HQPlayer Desktop 3>hqp-control.exe localhost --get-status
error: Connection refused

I am going ask some oblivious question so please bear with me.

 

You have HQPlayer running already  on the system when you are running the commands?

 

is there a firewall on your system?  If yes double check that the communication is not being blocked?

 

Edit: I get the same error message if I am not running HQPlayer already.

 

image.thumb.png.7d5f8bfcfe74927d7745167e4b6a96f4.png

Link to comment

It works, I can listen, but ... is this worthwhile?

I agree, I have a "poor" setup, only 4,500€ (Audiolab 8200 CD, Sonus Faber Tiny Towers and a Cochet AL-2, among others) and when I compared  what I get with HQPlayer with JRiver 24, WASAPI Exclusive, I'm unable to hear any difference.

The main problem is that HQPlayer costs more than 100€ ...

Link to comment
40 minutes ago, teodorom said:

It works, I can listen, but ... is this worthwhile?

I agree, I have a "poor" setup, only 4,500€ (Audiolab 8200 CD, Sonus Faber Tiny Towers and a Cochet AL-2, among others) and when I compared  what I get with HQPlayer with JRiver 24, WASAPI Exclusive, I'm unable to hear any difference.

The main problem is that HQPlayer costs more than 100€ ...

Only you can answer that. I would say that your’s is a pretty decent system for the money. When you use HQPlayer you’re paying attention to the source and whereas the Audiolab probably has an ok DAC, if you invested in one of the more affordable DACS, such as one of the ifi DSD capable DACs, you’d be more likely to hear the difference HQP can make. I realise that would mean further investment on top of HQPlayer. You’re obviously looking to improve your system though and the best place to start is the source.. Which PC are you running HQPlayer on?

Owner of: Sound Galleries, High-End Audio Dealer, Monaco

Link to comment

I have this one: https://www.hystou.com/fanless-mini-pc/broadwell-mini-pc/fanless-pc-i3-5005u.

4GB RAM, 32GB SSD (for the OS and the software), 2TB HD.

Controlled remotely by MSTSC, and RD Client on Android.

Optimized by Fidelizer Plus 8.2, Process Lasso and ... by hand (stopping services).

1% of CPU usage with JRiver.

Perhaps I shall invest those 100€ in a Linear Power Supply. Like this one: https://www.ebay.com/itm/122728397679

 

Link to comment

It's a different philosophy.

Here, in Italy, I'm in a Facebook group where people likes a lot software oversampling.

They oversample to DSD256 (at least), so that I understand why they need a lot of computing power.

Me, I'm convinced that it's not possible to get "blood from a turnip", so the information contained in a 16/44.1 cannot be "improved" by any oversampling (I checked that with a professor in "Communication Theory" @ Milan Politecnico).

More: since I know that my Audiolab 8200CD does his own oversampling, it can happen (as Archimago told to me) that the two processes (software-PC and firmware-DAC) interfere.

Perhaps HQPlayer is worthwhile with a NOS system.

Link to comment
1 hour ago, teodorom said:

It's a different philosophy.

Here, in Italy, I'm in a Facebook group where people likes a lot software oversampling.

They oversample to DSD256 (at least), so that I understand why they need a lot of computing power.

Me, I'm convinced that it's not possible to get "blood from a turnip", so the information contained in a 16/44.1 cannot be "improved" by any oversampling (I checked that with a professor in "Communication Theory" @ Milan Politecnico).

More: since I know that my Audiolab 8200CD does his own oversampling, it can happen (as Archimago told to me) that the two processes (software-PC and firmware-DAC) interfere.

Perhaps HQPlayer is worthwhile with a NOS system.

You have to experience something first hand before you can “know”.

Owner of: Sound Galleries, High-End Audio Dealer, Monaco

Link to comment
On 8/26/2018 at 8:50 PM, teodorom said:

Me, I'm convinced that it's not possible to get "blood from a turnip", so the information contained in a 16/44.1 cannot be "improved" by any oversampling (I checked that with a professor in "Communication Theory" @ Milan Politecnico).

 

DACs usually can do only 8x through digital filter, so the result is not perfect, resulting in left-over images around multiples of 352.8 kHz digital filter output sampling rate.

 

iDSDmicro-sweep-wide-std.thumb.png.823ebd18424fd6118057751638dccbc8.png

 

Upsampling 256x or 512x through digital filter allows moving these images high enough to be completely removed by the low order analog reconstruction filter.

 

iDSDmicro-sweep-wide-dsd512.thumb.png.602f5a371d63ce8471a407f33e0b4aa8.png

 

Meaning that the overall conversion accuracy improves. But you don't have to believe things, you can measure this yourself too.

 

On 8/26/2018 at 8:50 PM, teodorom said:

More: since I know that my Audiolab 8200CD does his own oversampling, it can happen (as Archimago told to me) that the two processes (software-PC and firmware-DAC) interfere.

 

Well, that doesn't happen. If you start from 44.1 kHz and output for example at 192 kHz. There's already huge empty space between old Nyquist and new Nyquist, so transition bands of the filters are far from each other. If they would overlap, it still wouldn't harm anything.

 

On 8/26/2018 at 11:20 PM, teodorom said:

Mathemathics is Mathematics ...

 

Yes, it is very clear from that perspective.

 

Here's an example, maybe more extreme, comparing DAC chip and HQPlayer. Left figures are DAC chip filters and right ones are one of the HQPlayer filters.

 

PCM5102-vs-HQPlayer.thumb.png.b9cfdffc378fb5eb104c73517ac2b009.png

PCM5102A-vs-HQPlayer-2.thumb.png.afe3693e4fdb64f82fa9f945712ec0aa.png

 

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Hi Miska,

for sure I agree with the statement "upsampling ... allows moving these images high enough to be completely removed by the low order analog reconstruction filter".

But ... please consider the fact that my Audiolab 8200CD upsamples to 32/84.672MHz, so 1920 times from 16/44.1KHz.

My DAC is quite old and quite inexpensive (900€), so that is not at the top of its category: e.g. the 8300CD upsamples twice more!

On the other side HQPlayer (I hope I'm not wrong) upsamples to 1.536MHz maximum.

So it seems to me that you are comparing apples with very, very, very old pears.

Anyway I agree that's a different philosophy. I had some Italian fellows that are upsampling by software (I don't remember which one) from 16/44.1KHz to DSD256 (or to DSD512). To do that they have very powerful (and very expensive) i7 with a lot of memory and water cooled.

Me, I have a "poor" fanless i3 where JRiver Media Center 24 uses less that 2% of CPU. 2% of an i3!

Link to comment
1 hour ago, teodorom said:

But ... please consider the fact that my Audiolab 8200CD upsamples to 32/84.672MHz, so 1920 times from 16/44.1KHz.

My DAC is quite old and quite inexpensive (900€), so that is not at the top of its category: e.g. the 8300CD upsamples twice more!

 

:D

No it doesn't, 8300CD uses ESS Sabre 9018 DAC chip which has exactly similar 8x digital filter restrictions. Rest of "upsampling" is just by repeating the same sample multiple times which doesn't do anything and then it is converted to 6-bit DSD-like data stream for the actual conversion stage.

 

Have you ever actually measured output of your gear?

 

Quote

Me, I have a "poor" fanless i3 where JRiver Media Center 24 uses less that 2% of CPU. 2% of an i3!

 

That is quite a lot of if it doing nothing else than shoveling data from storage to the DAC.

 

Quote

Anyway I agree that's a different philosophy. I had some Italian fellows that are upsampling by software (I don't remember which one) from 16/44.1KHz to DSD256 (or to DSD512). To do that they have very powerful (and very expensive) i7 with a lot of memory and water cooled.

 

Doing things without compromises can get heavy. 10€ DAC chips certainly don't do things the same way... ;)

 

 

P.S. I have to wonder why are you pulling topic of this DSP processing to a thread that is about JRiver <-> HQPlayer interaction?

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
1 hour ago, teodorom said:

No, sorry, I'm unable to do any measurement.

I read only what is in the  "Service Manual" (http://www.hifi-studio.cz/pdf/Audiolab/Manualy/8200CD-Audiolab service Manual v01 20101014.pdf) "x1920 times Oversampled with CD/USB 44.1KHz Source".

So, you are saying that it's a fake (marketing) statement?

 

Of course Jussi will answer himself but he did already say:

 

 Rest of "upsampling" is just by repeating the same sample multiple times which doesn't do anything

 

Link to comment

I checked that with a professor in Communication Theory here at the Milan Politecnico: adding samples in any way, adding zeros, doing a linear interpolation, a cubic interpolation, a spline interpolation, a "magic" interpolation, adds no information to the original signal.

In this sense whatever you do, you "don't do anything".

Mathematics is Mathematics.

Link to comment
18 hours ago, teodorom said:

I checked that with a professor in Communication Theory here at the Milan Politecnico: adding samples in any way, adding zeros, doing a linear interpolation, a cubic interpolation, a spline interpolation, a "magic" interpolation, adds no information to the original signal.

In this sense whatever you do, you "don't do anything".

Mathematics is Mathematics.

 

Of course it is not adding information, this is not at all about adding information. Please read some D/A and A/D conversion theory first and learn about images and aliasing. And what reconstruction filtering is about in D/A conversion.

 

https://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem

 

This is diagram of reconstruction filtering.

https://en.wikipedia.org/wiki/File:ReconstructFilter.png

Upsampling using digital filters moves the first image upwards so that it is not right adjacent to the baseband, thus allowing for example 2nd or 3rd order analog filter to remove it without spoiling the baseband. Analog filters are not steep enough to remove image of baseband because there's only 2 kHz space between 20 kHz and the Nyquist frequency where first image appears. You would need analog filter that rolls off within this 2 kHz band from 0 to -96 dB (for RedBook). That is not at all practical in analog domain, but can be done in digital domain using digital filters. In addition, analog filters cause phase shifts already below the corner frequency, so one would prefer to have the corner at least as high as 100 kHz to avoid screwing up audio band phase response.

 

https://en.wikipedia.org/wiki/Reconstruction_filter

 

Yes, this is all mathematics. And HQPlayer does a lot of it, while DAC chips have very little resources to do proper mathematics, so the result is compromise.

 

Btw, all the interpolation methods you mentioned are completely insufficient for audio.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
19 hours ago, teodorom said:

No, sorry, I'm unable to do any measurement.

I read only what is in the  "Service Manual" (http://www.hifi-studio.cz/pdf/Audiolab/Manualy/8200CD-Audiolab service Manual v01 20101014.pdf) "x1920 times Oversampled with CD/USB 44.1KHz Source".

So, you are saying that it's a fake (marketing) statement?

 

Yes and no, it doesn't state the oversampling is done using a proper digital filter. Oversampling can be done in many ways, good and bad. But just connect a proper wideband high resolution spectrum analyzer to output of the DAC and play linear sweep with peak-hold function of the analyzer enabled and you'll be surprised... That is what I do instead of reading marketing material.

 

I know how the ESS Sabre DAC chip (and other DAC chips) work and I have measured those. Much better source of information is datasheet of the DAC chip, instead of manual of some entire device.

 

But this is completely offtopic.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
On 8/28/2018 at 6:50 PM, joelha said:

teodorom,

 

Please start a new thread.

 

Most of us come to this thread to read or write about the topic described by the thread title.

 

Joel

 

 

Ok, so back to the main topic then; I discovered a bug in the last version I posted here, related to treatment of Multi-Disc boxed sets. I fixed that and decided to add a couple of features at the same time.

 

Up to now if you wanted to create temp files for any music files in J River that didn't require temp files to be created, you had to specify that in a custom library field in J River. You can still do it that way; but it's somewhat cumbersome if you always want to create temp files.

 

Now you can specify this in the 'call-jr-ps.cmd' file. Setting the 'alwayscreatetemps' setting to 'Yes' will result in temp files being created in all cases. You may do this if you believe the freshly created temp files sound better than loading the original file urls and you don't mind the slight delay that will result. The default is 'No' (without the quotes).

 

You can also specify the format for these temp files here using the 'tempformat' setting. The default is 'flac' (without the quotes).

 

Another feature I've added, which is also specified in the 'call-jr-ps.cmd' file is the 'view' setting. By default, this is set to 'Album'.

 

If you set it to 'Artist' all the files will be loaded for the artist who's view you are in within J River when you select a file to play. (Playback will commence with that file). Obviously there'll be no point in doing this if you only have one album by the artist concerned.

 

Remember to set this back to 'Album' when you want to return to the default behaviour, which is to load only the files to HQPlayer of that album.

 

Unfortunately there is no way of sending information about the J River view you're in to an external program, such as this. So you have to explicitly state it in the 'call-jr-ps.cmd', as I've described.

 

This has always been possible by adding a custom library field in J River to any single file of that artist. Again though, this is somewhat cumbersome, and you have to remember to set that custom field back to 'No', when you want to return to the default behaviour.

 

Finally, this same 'view' setting can instead be set to the name of a playlist which you have previously exported from J River to the same folder where this script and its other files reside. The playlist must be exported in .m3u8 format. The '.m3u8' is excluded from the name you specify in the 'call-jr-ps.cmd' file. Example view=Jazz High-Rez.

 

If you change the view setting to the name of a playlist in this way any file you choose to play in J River will result in the specified playlist being loaded in J River, rather than the album which contains the file. So remember to ensure you are in the view corresponding to this playlist in J River, and choose one of the files from this playlist for playback. 

 

Remember to set this back to Album again when you want to return to the default behaviour.

 

All views (Album, Artist and <Playlist>) may now also have a 'shuffle' mode applied. Set this to 'Yes' and the tracks will be shuffled when sent to HQPlayer.

 

I find this to be particularly useful for Artist and <Playlist> views, for example; to get an overview of an artists work.

 

Both of these alternative views can take a while for all the tracks to load in HQPlayer, especially when temp files are created. Because of this I've added another feature whereby the track selected for playback in J River for the Artist or Playlist concerned, is immediately loaded, and playback begins in HQPlayer, before all the rest of the tracks are loaded. This is the "instant gratification feature". It means that track selected for playback will appear as the first track in HQPlayer's playlist.

 

If you've set 'shuffle' to 'Yes' for an 'Artist' or 'Playlist' this first track will not be loaded again in HQPlayer, because the order is randomised in any case.

 

If shuffle mode is set to 'No' the track selected for playback will be loaded a second time in HQPlayer in its correct order. Since making it the first track and starting playback, was simply done to save you from waiting for the music to start.

 

In Album view we generally want to respect the order of the files. So you still have to wait for the file selected for playback in J River, to be loaded in HQPlayer, before playback begins. Albums though, are normally shorter than playlists or an entire artist's collection of tracks.

 

Finally, I've removed the "hqpnewerversion" option from this release, because I figure that anyone using this will be on at least HQPlayer version 3.20 by now.

 

To upgrade to this version you will need to unzip the attached file, open the 'J River to HQPlayer v1.15' folder then drag these files to the main 'jr-hqp' folder to replace the older versions of these files in the main package.

 

A long explanation, I know. There are quite a few changes in this release though. I hope all is clear.

 

Geoff

 

 

 

 

 

 

 

 

 

Owner of: Sound Galleries, High-End Audio Dealer, Monaco

Link to comment
18 hours ago, Geoffrey Armstrong said:

Ok, so back to the main topic then; I discovered a bug in the last version I posted here, related to treatment of Multi-Disc boxed sets. I fixed that and decided to add a couple of features at the same time.

 

Up to now if you wanted to create temp files for any music files in J River that didn't require temp files to be created, you had to specify that in a custom library field in J River. You can still do it that way; but it's somewhat cumbersome if you always want to create temp files.

 

Now you can specify this in the 'call-jr-ps.cmd' file. Setting the 'alwayscreatetemps' setting to 'Yes' will result in temp files being created in all cases. You may do this if you believe the freshly created temp files sound better than loading the original file urls and you don't mind the slight delay that will result. The default is 'No' (without the quotes).

 

You can also specify the format for these temp files here using the 'tempformat' setting. The default is 'flac' (without the quotes).

 

Another feature I've added, which is also specified in the 'call-jr-ps.cmd' file is the 'view' setting. By default, this is set to 'Album'.

 

If you set it to 'Artist' all the files will be loaded for the artist who's view you are in within J River when you select a file to play. (Playback will commence with that file). Obviously there'll be no point in doing this if you only have one album by the artist concerned.

 

Remember to set this back to 'Album' when you want to return to the default behaviour, which is to load only the files to HQPlayer of that album.

 

Unfortunately there is no way of sending information about the J River view you're in to an external program, such as this. So you have to explicitly state it in the 'call-jr-ps.cmd', as I've described.

 

This has always been possible by adding a custom library field in J River to any single file of that artist. Again though, this is somewhat cumbersome, and you have to remember to set that custom field back to 'No', when you want to return to the default behaviour.

 

Finally, this same 'view' setting can instead be set to the name of a playlist which you have previously exported from J River to the same folder where this script and its other files reside. The playlist must be exported in .m3u8 format. The '.m3u8' is excluded from the name you specify in the 'call-jr-ps.cmd' file. Example view=Jazz High-Rez.

 

If you change the view setting to the name of a playlist in this way any file you choose to play in J River will result in the specified playlist being loaded in J River, rather than the album which contains the file. So remember to ensure you are in the view corresponding to this playlist in J River, and choose one of the files from this playlist for playback. 

 

Remember to set this back to Album again when you want to return to the default behaviour.

 

All views (Album, Artist and <Playlist>) may now also have a 'shuffle' mode applied. Set this to 'Yes' and the tracks will be shuffled when sent to HQPlayer.

 

I find this to be particularly useful for Artist and <Playlist> views, for example; to get an overview of an artists work.

 

Both of these alternative views can take a while for all the tracks to load in HQPlayer, especially when temp files are created. Because of this I've added another feature whereby the track selected for playback in J River for the Artist or Playlist concerned, is immediately loaded, and playback begins in HQPlayer, before all the rest of the tracks are loaded. This is the "instant gratification feature". It means that track selected for playback will appear as the first track in HQPlayer's playlist.

 

If you've set 'shuffle' to 'Yes' for an 'Artist' or 'Playlist' this first track will not be loaded again in HQPlayer, because the order is randomised in any case.

 

If shuffle mode is set to 'No' the track selected for playback will be loaded a second time in HQPlayer in its correct order. Since making it the first track and starting playback, was simply done to save you from waiting for the music to start.

 

In Album view we generally want to respect the order of the files. So you still have to wait for the file selected for playback in J River, to be loaded in HQPlayer, before playback begins. Albums though, are normally shorter than playlists or an entire artist's collection of tracks.

 

Finally, I've removed the "hqpnewerversion" option from this release, because I figure that anyone using this will be on at least HQPlayer version 3.20 by now.

 

To upgrade to this version you will need to unzip the attached file, open the 'J River to HQPlayer v1.15' folder then drag these files to the main 'jr-hqp' folder to replace the older versions of these files in the main package.

 

A long explanation, I know. There are quite a few changes in this release though. I hope all is clear.

 

Geoff

 

 

 

 

 

 

 

 

 

!!!WARNING!!! Please don't download these files. I've found a serious error in the code and will update asap.

 

Anyone who may have already dowloaded them. Please trash and revert to the previous version.

 

My apologies!

 

Chris, if you can completely delete my previous post together with the posted files it would be safer. Thanks

 

Geoff

 

Owner of: Sound Galleries, High-End Audio Dealer, Monaco

Link to comment

Here is the corrected version (1.16) with corrected text:

 

Up to now if you wanted to create temp files for any music files in J River (including those formats supported by HQPlayer) you had to specify that in a custom library field in J River. You can still do it that way; but it's somewhat cumbersome if you always want to create temp files.

 

Now you can specify this in the 'call-jr-ps.cmd' file. Setting the 'alwayscreatetemps' setting to 'Yes' (without quotes) will result in temp files being created in all cases. You may do this if you believe the freshly created temp files sound better than loading the original file urls and you don't mind the slight delay that will result. The default is 'No' (without the quotes).

 

You can also specify the format for these temp files here using the 'tempformat' setting. The default is 'flac' (without the quotes).

 

Another feature I've added, which is also specified in the 'call-jr-ps.cmd' file is the 'view' setting. By default, this is set to 'Album'.

 

If you set it to 'Artist' all the files will be loaded for the artist, who's view you are in within J River, when you select a file to play. (Playback will commence in HQPlayer with that file).

 

Remember to set this back to 'Album' when you want to return to the default behaviour, which is to load only the files to HQPlayer of that album.

 

This same 'view' setting can instead be set to the name of a playlist which you have previously exported from J River, to the same folder where this script and its other files reside. The playlist must be exported in .m3u8 format. The '.m3u8' is excluded from the name you specify in the 'call-jr-ps.cmd' file. Example view=Jazz High-Rez.

 

If you change the view setting to the name of a playlist in this way, any file you choose to play in J River will result in the specified playlist being loaded in HQPlayer, rather than the album which contains the file. So remember to ensure you are in the view corresponding to this playlist in J River, and choose one of the files from this playlist for playback.

 

Again, remember to set this back to Album when you want to return to the default behaviour.

 

All views (Album, Artist and <Playlist>) may now also have a 'shuffle' mode applied. Set this to 'Yes' and the tracks will be shuffled when sent to HQPlayer.

 

If you've set 'shuffle' to 'Yes' for an 'Artist' or 'Playlist' the track you selected for playback in J River will be the first track loaded into HQPlayer and playback will start with that track as soon as it's loaded.

 

Finally, I've removed the "hqpnewerversion" option from this release, because I figure that anyone using this will be on at least HQPlayer version 3.20 by now.

 

To upgrade to this version you will need to unzip the attached file, open the 'J River to HQPlayer v1.16' folder then drag these files to the main 'jr-hqp' folder to replace the older versions of these files in the main package.

 

A long explanation, I know. There are quite a few changes in this release though. I hope all is clear.

J River to HQPlayer v1.16.zip

Owner of: Sound Galleries, High-End Audio Dealer, Monaco

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...