"Mastered for iTunes" is an invalid disambiguation

It’s the first you’ve heard of it because it’s not true.

2 Likes

You best learn to read and understand the process then. The facts are layed out to show that iTunes Plus is mastered differently than original iTunes. Just like you tell me that iTunes Plus is not a quality step, which in the words of Apple on their technical documents, says you have absolutely no idea what you are talking about. You words contradict Apple’s words and their technical documentation.

What part exactly is unclear? What fails to make sense when one is taken from a CD RIP and the other is not, and derived from earlier generations? Not to mention, are you aware that encoding is a mastering function? IF you will plainly state that what I said is not true, then show something to invalidate my documentation that says you are wrong.

Please review the definition of mastering, what it entails, and maybe even participate in some mastering work. Then, you can explain to me how using a CD as a master is not different than going generations prior, and instead of the standard CD mastering process, you encode (ie a piece of digital mastering) to the file.

It doesn’t matter whether you consider 1-click / 1-argument command line lossy audio encoding to be “mastering” or not. I don’t think there’s anything “invalid” about literally transcribing a sticker from the release into the release disambiguation field for the purpose of disambiguating one MusicBrainz release from another with a set of identical values in track count and medium formats.

3 Likes

Ok, that is a fair response, and in some degree, it makes sense I I would agree with you. But I have few points that cause me to make the statement, invalid. If you could politely see my reasons:

  1. " transcribing a sticker from the release into the release disambiguation field" – I agree here, except in the case of MFiT, there is no sticker on the release. There is not even a marking or any sort of indication on the release. It is only seen at the store. It would be my opinion that the sales floor does not really provide parameters of a release. This is a poor example, but we would not say that CD from Band xxxxxx is differentuated by an indication that track 8 is played most on xxxx radio station? I hope you see what I mean. There is a difference between a store display and data that is actually on, or contained in, a release.

  2. MB says they look at the release and the actual differences thereof. Thus, a sticker on a CD case makes a new release. I might be exaggerating, but again, please see my intent. So in that sense, yes, MFiT is a valid differentiator. But if that is the case, the difference between Amazon MP3 and iTunes M$A should not be combined as there is more of a product difference there than there is with MFiT. Same with original iTunes vs iTunes Plus. Agree or not, there is an audible and visual (stectrogram, etc) difference between the two. Which by MB standards, that is different as there is a clear sudible difference. Now, iTunes Plus to MFit, the differences there might be audible to a good ear. Otherwise, you will not hear it under normal listening conditions, so it is not a clear difference, which is what the guideline states. I believe that, please correct if wrong.

  3. You may have something on iTunes Plus AND MFiT available ta the same time. However, that also brings into account that releases by country cannot be combined. The example you provided showed, I believe as it is not in a language I understand but gave best effort, a release in one country store offering MFiT and a same release in another country store not marked MFiT. This is more interesting because if I look at the actual release, neither of them will say anything of MFiT in the metadata, but the country will be stated clearly. So if I were to try and identify that release, the country is more appropriate than MFiT … looking at a release, the actual release, should be able to differentiate it from others. This is the same logic that CDs, cassettes, etc have here, I believe. The package, printing, colors, printed barcode, etc … all attributes of the release itself, obtained and verifiable by looking at the release.

Please note that points one and two can go way more in depth, but no need for that. Also note that on point 3, you might have something there. But I do not believe it is a MFiT issue, but a country issue. I still have not seen 2 versions in the same store (country). I ask kindly, do you have more examples of that I Can look into? I speak from the standpoint of a product submitter, so I know that a submission is either approved for MFiT, or it is not. It does not go into both sections of the store,

As a side note … when you use a CD as a master, you are using a masteed product to produce another product. This is poor engineering and production. This is also what iTunes original mostly was, thus “CD Quality”. So once the source for iTunes (iTunes Plus series) stopped using a CD as a source, that is in fact a different master. Reason is not at all solely on encoding, but the fact that a generation before the prior source was used. So if a CD is mastered from its source, then using that CD is using a master that differs from its source. So taking said source and producing onto another medium, is in fact, a new master on all levels. This assumes we all understand mastering to be the preparation of an audio source to be replicated on a medium (in my own words). So on one side, we are replicating a CD (which is CD mastered) and on the other, we are replicating a pre-CD source onto digital. I hope I said that better.

1 Like

You make statements I agree with. But my point is, if you do not already have the barcode, the reverse lookup is of no value, therefore, making it not possible for the iTunes release owner to know the barcode. Yes, you are correct that in some cases the barcode is hidden within image links and such. But first, you do not know if it is correct and second, it is mostly NOT the case… but it has been there.

The only issue with your IRL example is that no one is stripping anything from the iTunes release. The fact is simply that the iTunes release never actually contains the barcode.

My point here is that the barcode is not disclosed to the iTunes release owner, at all. You can try and decipher it from web elements, but even at that, a reverse reference, or cross reference, does not actually mean the barcode is assigned to the release, but only that the said barcode is referenced to the release. You see this all the time… not everyone buys parts for things OEM, so there are references to part numbers of others, a cross reference. That is different from assignment. Unfortunately, iTunes does not disclose actual assignment to customers, just submitters. Referencing such things is a best guess at best… making it in my opinion, not worthy of an index of music release facts.

1 Like

I don’t think that a digital release is only the data that you can download. I think that a digital release consists more or less of the data that has been provided to a digital store. UPC and ISRC codes have been provided to iTunes by the music providers/submitters (iTunes FAQ).

From my viewpoint, iTunes barcodes are part of a release even though they are not included in the downloadable files. iTunes is not letting us download all the data that was provided to them so in that sense they are stripping some information from the end product.

I’m not sure what you mean by this. iTunes barcodes are provided by the submitters so the barcodes are always assigned to the releases. Even if the submitters use the same barcodes on digital releases as on their CDs, that’s their decision to make.

You’re right that it’s good to keep in mind that these kind of questionable sources can’t be trusted alone. In those cases we can and should verify the barcodes with the UPC lookup to be sure. (Relevant comment from an old thread.)

3 Likes

Agreed, all iTunes submissions are required to have a UPC and all recordings an ISRC. The ISRC is included in the file metadata, the UPC is not and is for internal use. I do ask this, if we are to consider store data as part of the release, then each store would be a different release? Each store is different, so applying that standard would have each stores release different. This is currently not the opinion of MB. Please note that I do not totally disagree with you here, but if we are to identify a release based on data only obtainable from the associated store, then stores will need their own releases as they all do offer different bits of data. Do you think that Amazon’s “AutoRip” then also needs its own release, as that is a “badge” applied to it by Amazon?

That is a fair point. I can see it as supporting data. It clearly as a different use and function than physical releases, and should someone find it important, it is in fact assigned in most cases. Only issue is that it cannot be used to identify a release (since it is not contained on the release) and is not at all disclosed to the customer via the standard shopping and support means.

That is fair enough, and that should apply to most cases. So I withdraw my statement as my point is based on the non disclosure of the barcode and not knowing the proper assignment, while your approach uses a logical conclusion and while we cannot actually verify it, the logic behind it is sound.

I agree with you here as well. If a barcode is entered, it should be verified for sure. Because this data is not disclosed, it requires searching and reverse searching to locate, so it should be verified.

Mastered for iTunes uses different mastering than other releases on iTunes. Just because it’s on iTunes doesn’t mean that it’s Mastered for iTunes. Look at your example. If you follow the iTunes link, make sure you are on the iTunes release page and not the Apple Music page. In other words at the bottom of the track listing, if you see “also available on iTunes” click that. if it says “also available on Apple Music”, you are on the right page. If the release has been “Mastered for iTunes” you will see a blue badge under the image that states this. If this is missing from page, than it has NOT been “Mastered for iTunes” and is likely the same release as Spotify, Deezer, etc. If it is there than it is a separate release than all other online releases. The disambiguation is there to help to not merge this release with other online releases.

4 Likes

You’re confusing recordings and releases. A different mastering on a release makes it a different release. A different mastering on a recording, does not make it a different recording.

Actually I have seen releases on iTunes, where one is “Mastered for iTunes” and one is not. They have different barcodes, as well. Your assumption that all iTunes releases are Mastered for iTunes is just not correct. Many of the brand new releases on iTunes are not “Mastered for iTunes” and therefore destroys any argument that all iTunes releases are going that way.

I never said this. It is one or the other, given the same store.

Per the Apple guidelines and tech documents themselves, this is going to be the new standard, with more changes to it. The MFiT is a step one into the change to 24 bit downloads.

Apple Music is a streaming service. iTunes is a download service. They are not the same at all, agreed. When I say “iTunes”, I mean iTunes, the download service, and not Apple Music, the streaming service. I have not looked at Apple Music to comment on the differences that may or may not be there in comparison to iTunes. Regardless though, iTunes and Apple Music are two distinctly different things.

On a personal level, I have sort of given up on this. MB can do as they wish, just as I can do as I wish. All I can say is that on the thousands of iTunes releases and individual songs I have indexed, cataloged, etc … what I am saying holds true on each and every one of them. Yet, when I use MB for data on those releases, I encounter issues with data. Thus the reason I no longer edit, or at least not at all like I did before, here. I am picky on my metadata, and the data that is used here is just not up to par. To each their own, but I no longer want anything to do with this topic until guidelines are put in place that fix the inaccuracies that the current guidelines cause.

They use the same URL! That’s what I was talking about. Many go to that URL and don’t realize that it typically defaults to Apple Music, never click on the Also Available in iTunes, and therefore never see the Mastered for iTunes badge. The reason for the disambiguation is that many iTunes releases have been both “Mastered for iTunes” and not. Many that came out before 2012, which is when MFiT started, have been updated. They are different releases. To make it more confusing, some even use the same URL, but they are still separate releases. I misinterpreted your “one or the other” as saying they were all the same, either they are on iTunes therefore MFiT. But I now see, that was not what you intended.

3 Likes

Ahh, ok. I see where the confusion was here. I agree iTunes is a total mess, I do not like Apple anyway, but I cannot discount their AAC encoder. It is the best there is unless there is someone making an encoder I am unaware of. Obviously speaking if compressed music. As a Linux user, I go through a fair deal of hassle to use said encoder, but it is well worth it.

I’m really agreeing with you now. After working with iTunes for over a couple of years, I have come to the conclusion that there really isn’t a difference between Mastered for iTunes and other releases. At least there really is no need to separate them from other releases if that’s the only difference. I’ll keep doing so, because I’m not sure about the consensus. However, let me explain this as others have. All Mastered for iTunes means is that the release has been mastered to meet requirements iTunes has. Why couldn’t a studio master a release to meet these requirements and then also send the same release to another outlet like Spotify, Deezer or whatever. There has been a series set up called “Mastered for iTunes” that can be attached to all releases that have the blue badge. I think that if the labels, artwork, tracklist, & barcode are the same, they should really be the same release. The disambiguation really isn’t necessary. I think we should merge all the releases that have the same barcodes, labels, etc. and just link to the series to reflect the “Mastered for iTunes” badge. The fact is with the knowledge of barcodes of iTunes, Spotify & Deezer that alone can show the difference between the releases.

1 Like

I only want to comment on one portion of your statement. You are 100% correct in that a company/artist/mastering engineer/etc is not going to make a master and use for most all. No one is going to make a master meeting MFiT specs and then create a lesser quality master for others. The MFiT initiative is meant to raise the bar of digital audio. In most cases, what it means is that the mastering engineer enforces standards that should have been enforced anyway, and does not bring down to 16 bit recordings that are of a higher bit rate to start with.

I would hope that any reputable studio is not recording anything at 16 bit, so what it really means is asking the mastering engineer to not degrade the audio like you do for CD standards and keep the higher definition… but also enforce standards to prevent digital clipping… which should have been done anyway. We as curators of musical history need to understand what is really going on. We owe it to ourselves and future generations of people to drop egos and opinions and address facts as they are. My opinions are against iTunes, but the facts make me hold them back.

1 Like

In practice, the barcode is usually not the same between the 16-bit AAC “Mastered for iTunes” release and other 16-bit releases. And because of this, it doesn’t matter how the music was mastered because “Mastered for iTunes” then serves its purpose as a real digital media release disambiguation.

One special case is that Warner Bros. Records has a practice of using the same barcode for the 16-bit AAC “Mastered for iTunes” release and the 24-bit lossless release, but you’ll have to fight pretty hard to convince everyone that a 16-bit release and a 24-bit release aren’t materially different.

If all are convinced that 16-bit and 24-bit are different releases, then the same can be said for MP3 and M4A, especially since there is more of an audible difference between the lossy formats than there is between the lossless formats.

Also, regarding barcodes, I will still say that barcodes are not a key factor on digital releases. Mainly because the digital release rarely ever contains a barcode in its metadata, and is also not easily available. Using iTunes as an example, iTunes does not openly disclose any barcodes.

I believe there is also a bit of a typo or misstatement here. MFiT releases are derived from a 24 bit audio source, not 16 bit. Additionally, once the AAC/M4A file is created, it is not a 16 bit audio file, it is a compressed audio file at a 256 kbps bitrate.

For reference:
“A 16-bit, 44.1kHz song requires a bitrate of 1.35 megabit/second of data, and a single minute of stereo audio takes up about 10 megabytes of space.”

I was only referring to 16-bit releases since that’s all iTunes offers. A 16-bit release on Spotify, Deezer & Bandcamp are the same release if they have the same barcode, If a “Mastered for iTunes” release has the same barcode as those, it’s likely the same exact release that has just met iTunes’ standards. I have seen a few “Mastered for iTunes” and HDtrack releases have the same barcode, but it’s uncommon. I agree in that instance they are different releases because the consensus is that different bit rate makes different releases.

Barcodes are easily identifiable on most iTunes releases. Every now and then there is one that’s difficult, but most have them in the “.jpg” cover art filename. They are easy on Deezer, Spotify, Bandcamp & HDtracks. So, they are definitely a factor. When iTunes doesn’t have it in the .jpg filename, they are usually the same as the Spotify barcode or can be found a lot of times at ISRC. Yeah, it takes a little time sometimes, but they are there. I really wish Apple would include barcodes in their API files, but they don’t, but if you find it in the filename or from another site, it’s easy to check against their API. Amazon & Google Play however, are a different matter. Never been able to find out what their barcodes are. And true maybe “Mastered for iTunes” are mastered at 24-bit, but they are definitely still sold as 16-bit, even if they are compressed.

1 Like

What I mean by availability of a barcode is a regular user is not able to easily find them. It is not listed on the site and not included in the files. Whereas a CD has a barcode printed right on, easy to locate. So if I open up my iTunes release, where is the barcode? It is not there. iTunes does in fact hide the barcode from the end user. It is considered internal use only.

AAC M4A files sold at iTunes are not 16 bit audio, nor are they 24 bit audio. They are 256 kbps compressed audio. Mastered for iTunes files are derived from a 24 bit source while iTunes Plus files are derived from a 16 bit source. An M4A COULD be made to contain 16 bit audio, but those sold at iTunes (AAC encoded) are NOT 16 bit audio.

EDIT: A 16 bit audio file uses 16 bits per channel. From there, we multiple 44100 by 32 (16x2) and we get 1411200, which is 1411 kbps. AAC M4A files from iTunes are at 256 kbps, far less than what 16 bit audio is.

EDIT2: I wanted to add to the prior edit. You will not expect to see all 16 bit audio at 1411 kbps. What that means is that 16 bit audio needs to have that available for use, not having to use. So for the AAC encoded M4A, the 1411 is more comparable to ~320. The more non technical general distinction is that 16 bit audio is lossless, AAC/M4A is compressed / lossy.