The way you are trying to do this isn't the best way to model it within Cassandra in my view. You build models based on your queries, not your data. If you need to find songs based by tag, then you make another table for that and duplicate the data. Something like ...
CREATE TABLE tagged_songs (
tag varchar,
song_id uuid,
song_title varchar,
... anything else you might need with your songs here ...
PRIMARY KEY ((tag), song_id)
);
The premise in Cassandra is that storage is cheap. Duplicate your data to meet your queries. Writes are fast, and writing the same data 3,4,10 times is normally fine.
You also want to store your song title and any other info you need into this table. You don't want to grab a load of IDs and try join on it when reading. This isn't a relational DB.
When someone tags a song, you might want to insert the tag into the set as you have it as present, AND add it to the tagged_songs table too. Querying for all songs with tag X is then basically O(1).