yeah everything is the same except that there are blank spaces in the songs instead of vulgar words etc
Does the clean version of the same album simply have tracks missing, were the tracks recorded with different lyrics, or does it beep for explicit words?
Different from producer to producer. Some perform some trickery, some insert bleeps or noise, sometimes it is an entirely new recording. If the track is missing altogether it is not usually called a clean edition but special edition etc or nothing at all.
I've just read up on this exchange; and in a quick test I'm also not getting any explicit album results (as in with the relevant 'AdvisoryRating' field set to Explicit) with various keywords, including some known explicit releases I have stored for reference.
As an example, a search (country= US) for the vulgar term "fuck you" (my apologies - no offense intended) yields the following results:
The first entry (id 432804574) is not stated as explicit; as the Advisory column remains empty, and I've looked in the raw data and found the "collectionExplicitness" key with the value "notExplicit". So, as per the iTunes database, this release is considered 'not explicit'.
However, looking into the raw data of the tracklist I find the following values:
"collectionName":"Fuck You (Official Karaoke Version) - Single" (--> again, no offense intended - this string was copied 'as is')
"collectionCensoredName":"F**k You (Official Karaoke Version) - Single"
"trackName":"F**k You (Official Karaoke Version)"
"trackCensoredName":"F**k You (Official Karaoke Version)"
"collectionExplicitness":"notExplicit"
"trackExplicitness":"notExplicit"
As previously mentioned by @poster
which seems to be the case.
I suggest repeating your searches with different localizations and see what works. The same keyword on the Canadian iTunes (country= CA) returns
and on the tracklist (in this instance) all profanity is explicit.
Amusingly, in the raw data of both query and album results, all explicitness-related flags indicate this release as 'not explicit'.
This is merely my opinion, but I think Apple decided to fiddle with the censoring logic of its database management, and it backfired.
As for my script, "if the source says it, then it must be true", because
Hopefully the issue will sort itself out in time.
PS: The "Censored/Uncensored" setting of my script does not apply to search results; it was a design choice to only identify explicit releases, not exclude them.
This filter is applied to select between the trackName and trackCensoredName keys (with the contents assumed to be correctly censored) at the track title level of album results (as that selection box was placed in the 'Track' submenu of the script settings to indicate as such). When I find the time, I'll review the relevant post to better clarify its purpose.
do you think it can be fixed?
That's really up to Apple to allow (a working) explicit search on their database. You can try their social channels and make your case there.
Whether they listen or not is up for debate.
Best of luck. ![]()
I've been using this source for tag processing, but in the last few days I found that it can no longer retrieve cover images for UK, Canada, or Hong Kong.
I'm confused, is there a newer version? please help, Thanks!
I've researched this, and it seems the issue is due to Apple's limit on parameter size.
My itunes.src version is quite old, so it might not look exactly the same as yours. Locate your .src file and find the following section:
outputto "COVERURL"
regexpreplace "100x100bb" "100000x100000-999"
sayregexp "(?<=\"artworkUrl100\":\").+?(?=\")" ", " "}"
Try changing 100000 to 9999. It should look like this:
outputto "COVERURL"
regexpreplace "100x100bb" "9999x9999-999"
sayregexp "(?<=\"artworkUrl100\":\").+?(?=\")" ", " "}"
After making this change, you should be able to find the cover art.
The maximum limit is likely 10,000
Hello everyone, I know you've already discussed this issue: the infamous Copyright tag on an iTunes M4A file that isn't transferred to an MP3 file by iTunes when you try to convert M4A to MP3.
I'm currently transferring it this way, which isn't the best and is quite time-consuming. In Mp3tag, I have both the M4A and MP3 files, I copy the data from the M4A file's copyright tag, and then I paste that data into the MP3 file's copyright tag...
Surely there's a better way to do this in 2026, to make it simpler and faster to copy the Copyright tag from an M4A file to an MP3?
Thanks in advance for your suggestions!

