# \[WS\] iTunes
**URL:** https://community.mp3tag.de/t/ws-itunes/13478
**Category:** Web Sources Scripts
**Created:** [May 24, 2012, 10:05am UTC](https://community.mp3tag.de/t/ws-itunes/13478 "2012-05-24T10:05:22Z")
**Posts on this page:** 10
**Page:** 18
### Author:  [@ghost](https://community.mp3tag.de/u/ghost)
#### Post date: [November 1, 2025, 12:07pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/349 "2025-11-01T12:07:31Z")
yeah everything is the same except that there are blank spaces in the songs instead of vulgar words etc
---
### Author:  [@AreDigg](https://community.mp3tag.de/u/AreDigg)
#### Post date: [November 1, 2025, 9:37pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/350 "2025-11-01T21:37:17Z")
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.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 2, 2025, 5:06pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/351 "2025-11-02T17:06:23Z")
> [@ghost](#):
>
> just checked and none of the itunes scripts show explicit albums
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:
```auto
"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
> [@poster](#):
>
> Perhaps Apple decided that, due to its well-known prudishness in some parts of US society, it should generally no longer be confronted with uncensored title names
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
> [@\[WS\] iTunes source script with multiple search criteria](https://community.mp3tag.de/t/ws-itunes-source-script-with-multiple-search-criteria/47197/55):
>
> My script is working perfectly..... parsing incorrect data form the source :
> And since there's no reference to validate if the data provided is correct, there's not much I can do.
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.
---
### Author:  [@ghost](https://community.mp3tag.de/u/ghost)
#### Post date: [November 15, 2025, 1:17pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/352 "2025-11-15T13:17:35Z")
do you think it can be fixed?
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 16, 2025, 4:35pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/353 "2025-11-16T16:35:59Z")
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. 🫡
---
### Author:  [@Newyouth](https://community.mp3tag.de/u/Newyouth)
#### Post date: [March 4, 2026, 8:49am UTC](https://community.mp3tag.de/t/ws-itunes/13478/354 "2026-03-04T08:49:37Z")
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!
---
### Author:  [@moebear](https://community.mp3tag.de/u/moebear)
#### Post date: [March 12, 2026, 4:28am UTC](https://community.mp3tag.de/t/ws-itunes/13478/355 "2026-03-12T04:28:17Z")
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:
```auto
outputto "COVERURL"
regexpreplace "100x100bb" "100000x100000-999"
sayregexp "(?<=\"artworkUrl100\":\").+?(?=\")" ", " "}"
```
Try changing `100000` to `9999`. It should look like this:
```auto
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
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [April 22, 2026, 6:35pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/356 "2026-04-22T18:35:38Z")
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!
---
### Author:  [@Newyouth](https://community.mp3tag.de/u/Newyouth)
#### Post date: [June 27, 2026, 10:09am UTC](https://community.mp3tag.de/t/ws-itunes/13478/357 "2026-06-27T10:09:06Z")
thanks! its looks work!
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [July 15, 2026, 11:07pm UTC](https://community.mp3tag.de/t/ws-itunes/13478/358 "2026-07-15T23:07:11Z")
To transfer Copyright tags from MP4 files to MP3 with Mp3tag
Here is the link:
> [@Mp3tag scripts to transfer all Copyright data from iTunes and other tagging programs, from MP4 files to MP3 files](https://community.mp3tag.de/t/mp3tag-scripts-to-transfer-all-copyright-data-from-itunes-and-other-tagging-programs-from-mp4-files-to-mp3-files/71614):
>
> Mp3tag scripts to transfer all Copyright data from iTunes and other tagging programs, from MP4 files to MP3 files. Context and Objectives This tutorial will allow us to copy our iTunes Copyright tags and those of recent and older programs from MP4 (m4a) to MP3. A huge thank you to @LyricsLover for their support on this project and for adapting my scripts and creating new ones. I also want to thank @ohrenkino, who provided invaluable support to LyricsLover. Their work is remarkable: a true pro…
[Previous page](https://community.mp3tag.de/t/ws-itunes/13478.md?page=17)