[Fou-Lu]

The first one is the only one of the two that make sense. It's scalable while the second is not and requires modification to both structure and queries in order to accommodate a new decade added (or more likely, an OLD decade added). I wouldn't suggest using either directly as you have here though; music has been around for a very long time. If I say I want from decade 2 for example, what year would that represent between? Only the 1970's? Or perhaps I want to pull from 1670 as well. Even just dealing with the past 100 years would have a problem (or you need to keep giving it new decade multipliers).
I would suggest using the entire publish year, and if you have an actual date for it, the datetime datatype would work for this. You can do some quick calculations based on the year to get just the "10" from 2013 for example. Or you can simply use BETWEEN syntax to find it.
If you really want to stick with a decade identifier, I'd suggest using a second table with that (a lookup table), or using an ENUM with the data you need. I like the lookup tables especially if you want to add more information. You'd simply use an identifier number (likely autonumber), the decade it represents (1980), and you could add some stuff like the type of music information if you really want.
Tagging systems themselves are simply a many to many relationship between a tag an and record. Decade tags carry no meaningful information on their own, and are equal in value to a genre tag. So I could tag a song with 1980, pop, rock for example, and can find that record by searching for any of the three tags, or refine as needed.

When you are designing, if you are in doubt, than lean in favour of data, not structure. It is far easier to manipulate data into a normalized structure than it is to hammer structure together that was built as afterthought.