Jump to content
IGNORED

iTunes - HQPlayer front-end re-visited


Recommended Posts

Hello Geoffrey,

 

I'm new to this discussion but was pointed here by ted_b since he's been helping me behind the scenes understand the finer points of HQPlayer.  I'm primarily a Mac user having begun my career at Apple in the late 1980s so I know my way around a Mac from a technical aspect pretty well although I stopped programming ages ago.

 

I've been eager to get your solution for iTunes -> HQPlayer integration working since most of my library is CD-rips in ALAC managed by iTunes, just over 30K songs.  In fact, getting this working will be a key driving factor of buying a license for HQPlayer at all.  But like DancingSea, I have not been able to get the script to work at all.  Like him, iTunes just plays through whatever its default mechanism is and not through HQPlayer, and therefore either of my DACs.

 

My hardware situation is this:

 

2008 Mac Pro (8 core, 3.0 Ghz), operating as a household media server, hacked to run High Sierra. (10.13.2 + Supplemental update).  16 GB of RAM, 1 TB hard drive boot drive.  iTunes directory on a separate Drobo external drive via USB.  Machine also functions as a Plex media server with DLNA turned on, mainly for LG televisions that can support streaming.

 

HQPlayer 3.20.1 (began with 3.20.0).

 

Oppo HA-2 portable DAC (a temp solution until I can afford better) in my two channel room.  This DAC connects through USB to the Mac Pro server.  It plays fine with iTunes using CoreAudio pointing to the DAC (instead of other outputs) or through the Tidal app.  And HQPlayer works with it on it's own dragging and dropping FLAC or DSD files which I have a small collection of.  Again, most of my library is ALAC, including HDTracks content.

 

Oppo 205.  This is being served by an NAA (2009 Macbook running Windows via Bootcamp).  HQPlayer works with this well over the network with the exception of DSD512 upscaling which seems to be past what my NAA can do.

 

I did try scrubbing the machine and reinstalling, making sure I had the latest version of your script and deleting the existing plist in my ~/Library/iTunes folder and I also scrubbed the .hqplayer folder as well.  The .hqplayer folder current has:

 

settings.xml (which looks like the settings for HQPlayer, including the current settings for Core Audio and the Oppo HA-2 target)

library.xml (an XML stub file with no settings)

current.m3u8 (a file listing the one song I had dragged into HQPlayer's playlist mainly to test it this morning  But I had asked iTunes to play a different song with no results.)

 

All settings are at defaults....everything local, no RAM disk, no other changes.  Your player will launch iTunes and HQplayer if i ask for that.  But otherwise, no music gets passed to HQPlayer.

 

And the HQPlayer Server temps folder (~/Music) is empty.

 

My desktop machine is another 2008 Mac Pro, also 8 core, 28 GB of RAM, again hacked to run High Sierra.  Another copy of my iTunes library resides on this machine but I have not tried running the script on it yet (or seeing if a network Mac-Mac solution would work).

 

Again, the script won't play to either DAC, either USB or NAA transports.  Quitting other applications on the server (like Plex) don't seem to matter.

 

One nitpick...my machine generally runs headless which means when I engage it through VNC screen sharing, the resolution isn't all that great so your setup dialog box is larger than the screen presented.

 

Thoughts?

 

Link to comment

Some more thoughts.  I decided to try it on my desktop Mac Pro which as I said earlier has nearly the same configuration as the server Mac Pro.  The only difference is more RAM (28 GB vs 16), slightly slower clock speed (2.8 vs 3.0) and four 6 GB drives in a RAID 5 configuration via SoftRAID instead of Drobo storage.

 

I installed it and low and behold, it worked!!!  And that was even though my NAA.

 

Well, it worked ONCE.  After that, it's not worked again.  HQPlayer works on it's own.  iTunes works on it's own.  But the Script server does not.  But I have noticed a few interesting things:

 

I decided to use the Ramdisk this time.  Files got written to the Ramdisk when it worked.  No files show there now.

 

When iTunes was playing something (even though HQPlayer wasn't doing anything), hitting the play button to pause or resume DID cause HQPlayer to do the same thing.  So there is some communication between the two.

 

So something weird is happening with the file manipulation section of the code.  No WAV files are being created and therefore, no links to them can be created in HQPlayer to play.

Link to comment

OK, Geoffrey and I spent over an hour today getting to the bottom of why the iTunes-HQPlayer Server was not working and we think we have a workaround until he gets the next version out.

 

@DancingSea, we determined that you MUST choose FLAC instead of WAV file creation.  There seems to be a bug in the Apple-provided utility that Geoffrey's been using to convert ALAC/AAC files.  He's creating FLAC files with the widely used FFMpeg library which works well on my Mac Pro server.  Apple's utility did create WAV files faster than FFMpeg but that's academic if it's not working at all in this application. 

 

And I probably had chosen FLAC when it was briefly working and then it got changed back to WAV and stopped working.

 

We also determined that it doesn't matter if your iTunes library is on the boot volume or not so you should be good to go with that.  My iTunes library is also on an external drive.

Link to comment

It all has to do with the method of programming that Geoffrey chose to do for this solution.  He chose Applescript, which is an interpretive programming language invented by Apple 25 years ago and was one of the few technologies that transitioned from OS 7/8/9 code base to the all new OS X.

 

If you're used to easy-to-use programming environments like BASIC or PASCAL, Applescript feels right at home.  The idea was to make it easy for a poweruser or programmer the ability to ask the Mac to do something that would have taken a long time to do.  Apple allowed many of their applications to respond to scripting requests, but these days, people do it to automate things with the file system, the Finder and iTunes.

 

But Applescript has limitations.  First, it's only available on the Mac so this solution won't work on the PC even though iTunes and HQPlayer exist there.  But the bigger issue to your question is that Applescript is an interpreted language, not a compiled language like C/C++/C#, Objective-C or Apple's new Swift.  Compiled languages are much faster since you use a compiler to convert your program that is easy to read for you into machine code that the CPU can understand and run at full speed.  An interpreted language like AppleScript or BASIC has an interpreter that reads every line of the code, converts it to machine code, runs it, then comes back to the next line, converts it, runs it, etc, etc, etc. 

 

This is extremely slow, by multiple factors over a compiled language (anywhere from 10X to 100X or more!).  Interpreted languages also usually have limited ways to interact with other programs using what we call APIs.  Compiled languages have total flexibility to do just about anything allowed by the operating system and other programs they interact with.  iTunes has APIs so that outside developers can ask it to do things (Applescript can take advantage of many of these).  And HQPlayer has integrated APIs into it's code too which is how programs like Roon interact with it.  But since Applescript is much slower, it can't interact with another program nearly as often as a compiled program, which can make it seems sluggish.

 

A better solution would be to take Geoffrey's program and make a compiled program out of it, rewriting it in something like Apple's Swift.  Swift was invented by Apple a few years ago as their next generation language designed for all things Apple (Mac, iOS, tvOS and WatchOS), but it's also open sourced now so you could use it in Windows or Linux systems too.  In my younger days, I would have loved to take the Applescript he did and see if I could do a Swift version but I've never programmed in Swift and I've really not done any real programming in 20 years.

Link to comment

Yes, after I wrote my post and went and opened the script editor and began looking at your code.  And then I looked up some of the specs for the ObjC bridge since you were indeed using it.  Nice to know that I can still deduce a few things after all these years of not programming. :)

 

Yes, you're right about Apple and inter-application communication.  I'm old enough to remember some of the first, long abandoned attempts at this in the System 7 days.  Applescript is one of the only things to survive that period.  Apple's sandboxing standards are strict...not sure that it's impossible to do any communication but again, it's been a very long time since I've even tried to do any of this.  I'll defer to your knowledge on this.

 

I'd also avoid anything to do with Carbon programming....surprised that still exists.

 

There is a Swift on Windows effort on Github.  Not sure if it's mature enough to do what you need.  With no Applescript on WIndows, it may be moot anyway.  Of course, ObjC on WIndows has existed since the NeXTstep days.

 

And there's always Java! :) (Hey, i work for Oracle...have to stick up for the home team).

Link to comment

Copy_of_a is right on the delay of the beginning of the first track.  I see this issue too.  There's a delay while it's creating the temp files...that's expected but then the music seems to always start about 5-10 seconds into the song.

 

Another issue I see is that sometimes the conversion doesn't happen if the file is an MP3.  i have a few stragglers in my library of mainly ALACs so this is weird.

Link to comment
3 hours ago, Lio_B said:

 

Great job Geoff :)

 

HQP started playing very fast, 2 or 3 seconds after iTunes and after each album switch.

 

Tracks of the album are always loaded in "HQP Server temps" folder but at each album change, temps files are deleted and the new tracks files appears, at the end, when I turn off HQP, all files are deleted.

 

thanks

 

 

Confirmed.  MUCH faster!

Link to comment

I have to again request @Miska consider adding ALAC to the list of supported audio file formats.  Many of us have tons of ALAC music and I'd rather not have to convert the whole thing and keep track of two libraries.  Not to mention that the format has been open sourced for several years...Apple even provides source code.  It would make we Mac users a lot happier using HQPlayer and make things like this program by Geoffrey a lot more efficient if it didn't have to spend all of it's time doing conversions...it could just have iTunes be a simple front end for HQPlayer with less complexity.

Link to comment
1 hour ago, Miska said:

 

Apple provides source for the ALAC codec, but not for reading the MPEG-4 container (.m4a) file where the content is. So quite a bunch of stuff is missing... I have my own old stream parser for MPEG-1 Layer I/II/III audio (aka MP3) container, but not for the newer and much more complex MPEG-4 container.

 

Alternatively, you could use a computer with HQPlayer Embedded and play straight from iTunes or what ever other player. Then you can play AAC (even DRM'ed), etc.

 

 

Isn't the MPEG-4 container well documented?  I mean, it's basically the old Quicktime container that Apple contributed to the MPEG-4 standard (MPEG-4 Part 14 ISO/IEC 14496-14)?  I still don't get it.

 

I don't understand what the difference is between HQPlayer Embedded and the other versions to "play straight from iTunes".  Could you explain how HQPlayer Embedded is getting it's "inputs" from your previous post?

Link to comment
2 minutes ago, Miska said:

 

Yes, it is well documented. Like many other things. Would just need to be implemented. How much extra are you ready to pay for it?

 

 

Normal digital or analog inputs, in addition to being UPnP Renderer and Roon endpoint. You could think it as similar to these devices, but instead running HQPlayer inside:

https://www.dcsltd.co.uk/products/vivaldi-upsampler/

http://www.esoteric.jp/products/esoteric/n01/indexe.html

So quite a bit more capable than those in terms of DSP.

 

 

Well right now it's probably the one thing holding me up springing for a license.  I like what I hear from HQPlayer but being a largely Apple centric household, I'm trying to figure out how I can integrate it into what I do here while not creating too much additional chaos.  That and I'd like a system my wife might actually could learn to use.

 

I'm debating getting a 2006 Mac Pro out of cold storage in my basement to run as a dedicated HQPlayer Embedded machine but I'm trying to figure out if it's worth the effort.

 

 

Link to comment
1 minute ago, Miska said:

 

Maybe not the easiest machine to deal with Linux, but it could work (it has PCIe slots?). If you are not familiar dealing with Linux, it is better to get some ready made box. Although AFAIK, nobody is offering one with those extra digital/analog inputs but there is one company offering HQPlayer Embedded servers otherwise (you could ask them for the input feature).

 

HQPlayer Embedded is Linux-only and still in beta... But lifts many of those source problems since it works even with old CD-spinners and new dongles like Chromecast Audio.

 

With HQPlayer Desktop, AFAIK, other alternative to this iTunes scripting with ALAC content is to use Roon as a front-end.

 

I've been dealing with *nixes since first experience on a VAX 11/750 running BSD back in college.  Yes, I'm dating myself.

 

The 2006 Mac Pro does have PCIe slots, but sadly, only version 1.  Still, that's better than nothing.  Since it cannot run the latest version of Mac OS anymore, it may make a decent Linux machine.  I had retired it for the "newer" 2008 Mac Pro obtained from a friend and I have it running as my household iTunes/Plex server. It might be useful in this application running -2s filters due to its age.

Link to comment
19 minutes ago, Miska said:

 

OK, then it is probably not hard for you at all to install Linux and my package and do a little bit of configuration! Of course it is still quite a bit of time and effort.

 

 

I keep an old Sun Ultra 10 workstation in my basement but alas, it ceased working some months ago and I haven't tried figuring out why.

 

Sadly, the 2006 Mac Pro doesn't meet your SSE4.2 requirement so i can't use it.

Link to comment
56 minutes ago, Geoffrey Armstrong said:

Anyone looking for something truly family friendly will love Roon. It's the best user experience combined with the best sound, thanks to HQPlayer.

 

I only wrote this Applescript because I also like to use iTunes from time to time, having grown up mainly with Apple hardware.

 

I have to confess I do also buy lossy Apple tracks from time to time when it's the only way to get hold of some music I want, instantly.

 

I don't understand why anyone would choose my Applescript over Roon, unless they were really married to iTunes. Of course, iTunes is ubiquitous and free with every Mac. So there is the financial issue. In my view though, anyone who's passionate about music would be very happy with the Roon/HQPlayer combination.

 

Just getting back to the subject of my script; I was kind of hoping on some feedback of the sound quality of those temporary files, compared with loading the original file urls (for people who are able to make that comparison).

 

When all the software is running on the same Mac and the temp files are being written to a Ram Disk, the creation of the temp files, and loading the first one, is actually very fast in my experience That's using a 2013 Mac Pro.

 

So I'd love to hear from people who've compared the sound of the freshly minted temp files, with file urls of the same music. Also comparing the sound of .flac temp files with .wav temp files. Anybody?

 

Thanks

 

Geoff

 

 

OK, I'll bite. :)

 

Why would I want to do your Applescript over Roon?  Simple...cost.  Not all audiophiles have completely elastic budgets and lifestyles.  Yes I bought an Oppo 205 last year but I saved for months out of our household budget so that it wouldn't end up getting parked on a credit card.  And I have my eyes on further upgrades for my two listening rooms that I'll need some budget flexibility for.  Adding another subscription service chips away at that to the point that I can't make the argument to my wife.  And right now we have cable (we still watch TV and need very high speed internet since I work from home and work in tech), Netflix & Hulu (both actively watched,) Amazon Prime and iCloud (backup and services for all the Macs/iOS devices in the house.  And I replaced Spotify for the more expensive Tidal.

 

I'm sure Roon is great.  I even has a 60 day trial I haven't pulled the trigger on with the purchase of my Oppo.  But my fear is that if I start the trial, I won't want to end it.  And $10 a month here and there adds up fast.  One of these days maybe the cost won't matter as much.  But right now I'm trying to keep the household budget from creeping up again.  We've already seen that happen in the last 6 months and I have to be better about it.

 

As for the quality of the temp files, everything sounds perfect, as it should.  It's all just math.  And with lossless encoding and decoding, it's no different that any other mathematical compression of a file that we may want to send somewhere and be decompressed on the other end.  If the math weren't correct, we'd just hear garbage on the other end.  And in the end, it's all just PCM data anyway.  FLAC, ALAC, WAV...it's all just different wrappers on the same information.

Link to comment
12 minutes ago, Geoffrey Armstrong said:

I've just tested and you're absolutely right. I need to look into this. Thanks.

 

If you create temp flac files it does respect the original 24bit. So as far as high-rez is concerned flacs are definitely superior for the moment.

 

 

Wow.  I think I've been listening to all CD-Redbook rips of late so I wouldn't have noticed.  Back to FLAC for the meantime!

Link to comment
1 hour ago, Geoffrey Armstrong said:

That's a perfectly understandable reason, and I mentioned the financial issue in my previous post.

 

I think you also mentioned that to me during our TeamViewer session. We all suffer from those tempting subscription costs mounting up and it's easier to lose track of them nowadays than ever.

 

I guess the guys at Roon decided to peg the definitive price of the software high, for the lifetime one off cost; but offer subscriptions to people who felt that would hurt their cashflow too much.

 

On the subject of the temp files, I think there is a difference between the sound quality of a newly created file on a Ram disk (the temp file) and just playing the file by loading its file URI from wherever it's located on a hard disk, NAS or internal SSD/Fusion drive.

 

Some even say that keeping the path lengths as short as possible improves SQ. If that's true it will also be helped by the Ram Disk.

 

As to whether WAV is superior to FLAC or visa versa, I won't get into that. I'd like to hear opinions on it though.

 

Roon has bills to pay and maybe investors to repay as well.  And considering their small customer base of audiophiles, I'm not surprised at their pricing strategy.  For many of their customers, writing a $500 check isn't even enough for petty cash.  But I'm not one of them and even adding another $100+ item to the yearly budget would probably get flack in my house.  And I'm still trying to talk my wife into replacing the subwoofer in the home theater that failed two years ago.

 

As for where a file sits concerning its sound quality, I have to respectively disagree.  Data is data is data.  It doesn't matter where it sits or in what form.  Arguments saying that a shorter path name makes a difference in sound quality are completely bogus.  Data is stored in iNodes in nearly every disk operating system invented in the last 30 years and the path is merely a representation that we can understand.  What really matter for using a RAMdisk is latency...working from RAM memory is indeed faster if you're trying to do additional processing on the file (like HQPlayer) or feeding it to some sort of a device (like a DAC).  But these files aren't usually large enough that latency plays a big difference with modern PCs...any spinning disk is faster than the USB 2.0 interface anyway.  RAMdisks are also not as important these days with the advent of fast SSD drives which helps the latency equation versus spinning disks (which are all faster than 20 years ago as well), not to mention the noise that hard drives can make.

 

One last point on cost.  I've been trying to figure out if I spring for a HQPlayer license what the true cost of using it will be.  I've already talked about trying to resist adding a Room subscription as another yearly cost (I neglected to mention i subscribe to Backblaze for data backup which I consider crucial).  If I look at the future of HQPlayer, it's clearly in the version 4 codebase which is right now in beta for the embedded product.  That version of HQPlayer requires SSE4.2, which might end up being the minimum requirements for all platforms (Miska?).  If that's the case, none of the elderly Xeon machines in my stable could run that (the 2008 Mac Pros are all SSE 4.1 machines).  It's not possible to upgrade any of these machines to Nehalem-class processors which would satisfy the requirement.  That means I'd have to look for a  newer machine to do this.  For old Macs, that would put the 2010 Mac Pro as the oldest that could support this but I'd be reticent into putting money into a machine that Apple is likely to obsolete later this year (both of my 2008 Mac Pros came free from friends who were upgrading and I help them with their Mac needs).

Link to comment
1 hour ago, Geoffrey Armstrong said:

I've just tested and you're absolutely right. I need to look into this. Thanks.

 

If you create temp flac files it does respect the original 24bit. So as far as high-rez is concerned flacs are definitely superior for the moment.

 

 

Yes, I just confirmed this too.  I have one album in my collection which is represented in both Redbook and 24/48 from a DVD-A rip.  So the AppleScript rips both versions of the songs to the Ramdisk.  VLC shows that the 24 bit file gets changed to 16 bit if you use WAV (but still keeps the 48 kHz sample rate) but it's keeps 24/48 if the file is FLAC.  One weird bit is that VLC doesn't properly display the codec information for a 16 bit FLAC file...not sure what's going on there.  it doesn't seem to affect playback.

 

One more minor (but annoying bug).  If you're stopped playback and then select another song, you'll here a second or two of the previous song before the new song kicks in.  Not sure why.

Link to comment
1 minute ago, copy_of_a said:

because you didn't "stop" the song. you've just "paused" it.

"Stop" (in iTunes) also stops HQPlayer, disconnects from the file and clears the temp files (from HQPlayer's playlist as well as from the disk).

 

Yes, i suppose that's a distinction between iTunes and HQPlayer.  But as far as I know, iTunes doesn't discern between 'pause" and "stop".  It's the same thing.

Link to comment
11 minutes ago, Geoffrey Armstrong said:

You're welcome and I'm glad you appreciate it!

 

Everyone using this please replace iTunes - HQPServer with the new attached version. This corrects the 24bit bug when creating temp WAV files.

 

The problem was that I didn't realise I needed to specify 24bit when converting to WAV in FFMPEG, which is not necessary for FLAC.

 

You should find this version respects the 24bit sample size correctly when creating WAV files.

 

Geoff

 

iTunes - HQPlayer Server.app.zip

 

Still seeing 16 bit...let me check again.

Link to comment
12 minutes ago, copy_of_a said:

works as supposed to on my Mac.

I've not only replaced the app but also deleted...

~/Music/iTunes/iTunes - HQPlayer Server.log

~/library/iTunes/itunesHqpserver.plist

... before updating and running the app, though

 

Still only seeing 16 bit after doing additional housecleaning.

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...