"Mastered for iTunes" is an invalid disambiguation

Please quote the relevant material. Reading the document, it seems to me that iTunes Plus is just used to refer to files that have “a variable bit rate (VBR) 256 kbps AAC encoding format". It’s not a mastering process.


First, “The iTunes catalog was initially offered in 2003 as 128 kbps AAC files, many of which
were encoded from the original CD masters. They sounded great—in fact, these
downloads led the industry in sound quality.” -->> this discusses the original version, being taken from CDs and made digital. Thus, again, “CD Quality”, which was 128. If proof of that is really needed, ask and I will provide.

Next we have, in part this:
“Master for iTunes Plus
When creating a master, mastering engineers take into account the limitations and
characteristics of the medium or destination format, as well as the listening environment
of their audience. For example, a master created for vinyl is unlikely to be listened to in
an airplane or car, and therefore is often mastered for a listening environment where a
listener can hear and appreciate a wider dynamic range. Similarly, a master created for a
club environment might take into account the noisiness of the intended listening
environment.” -->> this explains that when you submit a “iTunes Plus” release, there are other factors that you give attention to, aside from just using a CD master.

You can see here, by looking at the initial methods of using a CD as master to taking other factors in consideration under the scope of “iTunes Plus” clearly means that there is in fact a difference in the mastering. If it is not clear to all, things like dynamic range, clipping, One must realize that thing like this are not a byproduct of playback, but a result of the mastering process. You get things like distortion and such from the process of mastering, not a result of the playback. You play what was created. Additionally, one must realize that encoding is a form of mastering. So even if there was nothing done aside from the standard “take the CD master and use it”, there is still a process being done here.

If we query the definition of mastering, we see " Mastering , a form of audio post production, is the process of preparing and transferring recorded audio from a source containing the final mix to a data storage device (the master ); the source from which all copies will be produced (via methods such as pressing, duplication or replication).". Now, lets us also look at encoding. During encoding, we are “preparing and transferring recorded audio from a source containing the final mix to a data storage device”.

So, on multiple levels, iTunes Plus is in fact mastered differently. Changes to things like loudness, clipping, dynamic range, etc are all a part of the mastering process. So if one is to consider these factors in the said processing, we obviously have a difference in mastering. Otherwise, iTunes files (ie iTunes Plus) would simply be a rip of the CD, which it is clearly not.

EDIT: As I think if I explained well enough, I want to add this. The “master” for the original iTunes was mostly a CD. That means the “master” was a CD. With iTunes Plus, the “master” is not a CD. The “master” is derived from earlier generations of the product. Thus, mastered differently, as a master that is different from another is in fact different.

EDIT 2: I quote “Mastering, which is the process of creating the delivery media that will allow the audience to access the material. In the case of iTunes, this includes encoding an Apple AAC file and adding the appropriate metadata.”. -->> So for those who understand the process, knowing that iTunes Plus is mastered differently than the original iTunes should not at all be something unheard of, but simply a given fact.

This thread was not really intended to be a education tool on how mastering works and what it is. There have been enough people telling me that I know not what I speak of, yet when it comes to facts, ignorant parties shine clear as day. There is plenty of overwhelming proof that MFiT is less significant than iTunes Plus as it relates to the end users product. So if a distinction is not made for iTunes Plus, a distinction, as this thread is titled “Invalid Disambiguation”, is not argumentative, but based on real facts.

1 Like

This might also speak to the relevance of MFiT. Please note these are not my words, this is 100% quote.

1 Like

Any mastering engineer worth his salt will prevent things such as clipping anyway, and that’s easier than ever these days since pretty much all (digital equipped) studios will be using 24 bits all along their production line.
They don’t need any Apple software for that.

They will probably also consider to master it with some focus on how it will sound on radio, in a car, on high-end equipment, on vinyl, on CD, on television, or when it gets encoded (degraded) to mp3/aac.
These engineers have been doing that for years and years before Apple found a very clever way to monetize on the basic and long existing concept of good mastering, and put a pricey label on it.

I’m not well versed in how ‘digital’ is handled on MB at all, and I am not sure I understand the general intention and possible repercussions of this topic, but I think it would be a little bit weird if there would be a category for factually only describing if an engineer used a specific brand of (commercially hard pushed) software for his job.

It’s like putting a label on: This house was build using water level tools by Stanley™.
And here we are speaking about software that will not do anything to the sound quality at all if the engineer was doing his job well in the first place.

Well played Apple™©®


Well said.

Yep, exactly. This should all be done in the first place, not something to get a gold star for.

Based on my few encounters with MFiT releases during this year, they seem to always have different barcodes when compared to Bandcamp, Spotify or other services which show barcodes. My view on barcodes on digital releases has leaned more towards keeping releases with different barcodes separate. So from this point of view it doesn’t matter whether MFiT has any real effect on the music files.

I believe that an implementation of release variants (as discussed somewhere here) can be a game changer for digital releases. I don’t think a separate thread was ever made for them but it’s a good time to bring the discussion back to the table.

Edit. Edge case found: https://musicbrainz.org/edit/56483517 (MFiT release which has the same barcode as on Spotify and Deezer)


Could you direct me to where iTunes/Apple shows us the barcode of a release? I know you can lookup a barcode to a release, but not a release to a barcode. To me, that puts into question if said barcode is in fact correct and actually assigned to said release.

Additionally, as it relates to this specific thread, iTunes files do not contain barcodes in them, meaning there is no barcode in the metadata. This differs from a physical release. First, if a physical release does not have a barcode printed on it, you mark it as having no barcode. Well, digital releases do not have a barcode “printed” on them, again as it relates to iTunes. I would assume we can consider the metadata as the “printing”, as the metadata is sort of a equiv to the paper covers on a physical release.

To put it really generic … if I have 2 CDs, I can tell you which has which barcode. If I have 2 digital releases, how does one determine the same? The information that is in the files are things like ISRC, which MB does not consider as differentiating information… so why would MB consider a barcode, which is not even “on” the release, important?

I do hear what you are saying, but barcodes do not apply at the same level as they do with physical releases. This becomes very clear since it is usually not even disclosed on a release what the barcode actually is. If I look at my release and cannot find said information, it is not identifying information.

EDIT: Per the guideline, all iTunes releases should be checked as no barcode, as I can assure that there is no barcode on the product… which is the criteria for indicating no barcode.


The barcode is sometimes hidden in the cover art url. I don’t know other ways to find out an iTunes-specific url. For example:

As not everyone knows that you can lookup iTunes barcodes, here’s an example of that too:

Hmm? As long as the release stays in iTunes, you can just lookup the barcode. After the release has been removed, it gets trickier. In that case we would mostly just have to trust the original editor that they submitted correct data.

There is no barcode on the product after it leaves the store. An IRL example would be a cashier stripping barcodes from products after scanning them. However, the guidelines are not against taking barcodes directly from stores in case of digital releases. If someone wants to investigate digital releases and add in more effort, more power to them – as long as the data is correct.

If two albums have a non-mastering-related reason for having different ISRCs, they would be two releases. I don’t think that being able to tell which exact release a digital file represents is something MB should focus on. I guess barcodes are just more or less interesting data. Also they can be useful in separating different releases in MB.

Tagging-wise I’d be happy with just one base digital release in most cases. I’m not interested in classifying where exactly a digital album came from. I’d be okey with just knowing that it is a digital release. That’s where I think the base release of release variants would be useful.


I think you may have been refrained from creating new recordings if the sound was not drastically different.
Commenting releases as (2017 remastered edition) and things like that is completely legitimate IMO to disambiguate releases.

But different format, encoding, etc.
If it was only me I would put all same tracklist digital releases in only one MB release with [all the barcodes attached](https://tickets.metabrainz.org/browse/MBS-3978 if one really wants barcodes and all catalogue numebrs and all cover arts attached there.
I’m a fan of having distinction in all the physical releases but absolutely not for digital releases.

1 Like

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


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.


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


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.


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.