I don’t know how to do it, so I’m asking the script makers (you know who you are :-). ) to make an importer for HD Tracks. It seems to me it’d be relatively easy as all HD Tracks have a very easily accessed API. Example:
Please install it from the above page (by clicking the Raw button) and give it some testing to see if it works as expected for you (before I will submit a PR to include it in murdos’ repository where most of the other importers have their home). I have only tested the userscript without having an account there, so let me know if it behaves different for logged in users.
There were also some decisions I had to made on which I would like to hear your thoughts:
Link type: purchase for download (you can’t stream music there, can you?)
Release country: empty (definitely not worldwide, see screenshot above)
Script: Latin (I have seen nothing else, not even for K-Pop releases I had a look at)
Disambiguation: e.g. 192kHz/24bit
Annotation: (C) & (P) copyright lines, release credits (unclear to which tracks they apply)
→ both could also be copied from the page manually
As an aside, I really should document the seeding protocol for magicisrc - it actually supports an alternate parameter form like isrc2-12=XXX to set the isrc for track 12 on disc 2, if your source has the discs in the release separated.
A rather short test. It seems many releases are not available to German customers. Even specifically German releases. Guess I have two reasons now to ignore HDtracks ¯\_(ツ)_/¯
Funnily enough the sample streams do work.
All the while it’s available on other platforms. Same barcode mind you:
So according to the spare explicit (thanks @chaban) and implicit feedback I should probably…
Drop the release credits from the annotation (there are better sources for credits and you can still copy them after clicking the (i) button if you want to).
Keep the copyright lines from the API as annotation (they are sometimes different from and/or longer than those shown on the page).
Stop using the resolution as disambiguation comment since the barcode is sometimes also used for standard resolution on other platforms? Maybe it’s safer to add this into the annotation (e.g. as “24bit/192kHz available on HDtracks”).
Not completely sure about the last point, I have seen many of these disambiguations and I don’t want to stop people from adding them if this is accepted. Any thoughts or comments?
P.S. Unfortunately there seems to be no reliable way to split fields with multiple artists (joinphrases are ambiguous) or multiple labels (only separated by spaces).
That’s what I’ve been doing. I’ve just been adding it in the annotation, just like you stated. The lines are getting blurry. Apple Music has hi-res now, but they don’t advertise it on a release page. The only way you’d know is to right click, go to “view page source” and search for “audiotraits”. But how many editors check. Very, very few would do that, and I couldn’t expect them to. a-tisket wouldn’t know the difference about it, so it would get lumped automatically in with the Spotify & Deezer release if they have the same barcode, which many of them do. That audioTraits value also will tell you if it’s Spatial Audio, Atmos, mono, stereo, etc.
I don’t think we will see another physical format. CD is already dying off. One day MB will wake up and give us a way of showing this kind of data in a recording. Trouble is we still have people who think a 320kbps MP3 is the same as a hi-res Atmos track. Such a pity none of this can be documented, but MB hasn’t even worked out how to show mono\stereo\5.1 SACD recordings apart.
I have now updated the importer to drop the release credits from the annotation.
The audio quality is now included in the form “192kHz/24bit available on HDtracks” and will only be added as disambiguation comment if it is not the standard quality of 44.1kHz/16bit. So it’s up to the users to decide whether they want to keep that information.
In addition I have fixed a small release date bug which lead to dates that were off by one day if the user’s timezone is UTC-x.
If you don’t want to wait until the above PR is merged, you have to update the script manually (for the last time), until then automatic updates will not work.
Sometimes the hi-res release has a different mastering engineer than the 16-bit release. If so, they really need to be separate MB releases, even if the identifiers look the same, because the release-level relationships will differ. (However, the current industry trend seems to be to create one hi-res master which is used for both the CD release and the digital formats, or at least only use one mastering engineer for all masters.)
Sony Music Japan has changed their practices several times. They used to assign a different catalog number and barcode; currently they don’t; and they’ll probably do so again in the future.
I’ve never seen a different release with the same barcode with different mastering. To me it’s not any different than playing an audiophile 180g record on a bad record player. It’s not the releases fault, just the technology that delivers it. It’s no more apparent than the fact that Apple just all of a sudden turned millions of their 16 bit releases into 24 bit releases over night. Because they already had the release, they just updated their software to play it. Many times I go to a release on a “hi-res” site, they offer the same release in different formats and you can just pick the one you want. Same ID, Same barcode, etc. Do you want to add the different ones as different releases, even though they have the same barcode and link, etc. It does appear that the sites are getting better at it though. Also, iTunes now has hi-res lossless on many of their releases. You wouldn’t know this without loading it in the app or looking at the “view-source” data on a page. They don’t advertise it on the release pages. They will be added as the same release as Spotify and Deezer and have been by the 1000s by a-tisket, because an average editor wouldn’t even know they were different. Honestly, I haven’t seen people separating them out for a few years until very recently. Of course, if there is anything different on a release it can be a separate release, I just fail to see how 16 bit or 24 bit, etc. is enough to say it’s a different release, when it’s only the limitations of the site that are the issue. I’ve changed on merging them, but unless I can figure out a clear difference by comparing the data, I don’t think we should ask people to separate out that hi-res Apple Music file from that CD quality Deezer link if everything else is the same. Mainly because when I stream them, it’s only CD quality because I’m not spending the money for hi-res lossless. It’s still the same release. I’m able to play it. It just doesn’t sound as good as it’s full potential.
I agree here, especially as it is very common to have different download options in various formats, in case of streaming services the quality often even changes dynamically without the user necessarily noticing.
I think listing every possible format doesn’t make sense, especially as the source material is stored lossless and store fronts will just add and remove downloadable formats as technology advances. What is of interest to me is the highest available quality, that is something that IMHO should be noted in MB. But as you also explained even this is not fixed. We don’t know what the highest possible quality is the store could offer.
This is actually an argument in favor of splitting them for me when the store considers them to be different products. If you buy the 16bit product on a store, you don’t get access to the 24bit/48kHz or the 24bit/96kHz. You have to buy those versions separately. It’s similar to how you have to buy separate editions of the CD separately.
(Not counting Bandcamp where they probably transcode from 24bit to 16bit, and thus neither the store nor the artist/label consider them to be different products.)