# \[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:** 1
**Showing post:** 351

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@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")

</div>

> [@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:

 ![imagem](https://community.mp3tag.de/uploads/default/original/3X/0/4/043cb74435215eb7a12d58eac834846de50da9b0.png)

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

 ![imagem](https://community.mp3tag.de/uploads/default/original/3X/9/5/95b44867d4156012475ca3b16125ca0a7a06c530.png)

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.

---

_[View the full topic](https://community.mp3tag.de/t/ws-itunes/13478)._