Bob_m_54 wrote:That won't matter, one step and all his files will have the genre tag the same as the genre folder they are in...
Well then, in a multiple genre situation, I guess I still don't get how pasting in a single genre, like "rock", and then just changing it to \<Genre>\,
before accounting for anything else, will assign the genres from the folders to the tag fields if they are missing from the fields to begin with.
Maybe, I will test it out some time with the "all" multi-genre scenario. Anyway, don't worry about it.
One question for me though, do you find an advantage in storing the files according to genre? If so, what is the reason?
the way I store mine is like this example for say Rolling Stones.
Code: Select all
[Music Collection]\Music\Flac\R\The Rolling Stones\1971 - Sticky Fingers\01 - Brown Sugar.flac
I approach my structure with the idea, "what if I didn't have a fancy program that organizes everything a trillion different ways".
What if I had to just rely on a very basic player and my folder sturcture, or I didn't have access to a player and just wanted to browse/assess
the library with the structure?
- First, I consider how important the music is to me (simple abbreviated code)
- Second, I don't like using conventional genres, as is (also wording them out), so I came up with a genre code based on conventional ones (abbreviated
and combined with genre code). [I use a custom field for album/song specific genres/sub-genres (don't always fit to a single genre) and write them out like convention]
"Importance/Genre" and "Album Artist' would be combined as a single folder
- the "Year" (followed by a sequence letter; A, B, C) and "name of the album" (combined as a single folder)
- the track name as track# and Title.
So you might have something like this,
Code: Select all
H:\AMI.A1.P0\(RP0) H1a Led Zeppelin\1969B Led Zeppelin II\01 Whole Lotta Love
AMI.A1.P0 = "Audio, Music, Internal"."placeholder for ordering" (other folders involved at top level)."Primary Core"
and so on...
(RP0) H1 = (Rock, PrimaryCore) Hard (intensity degree of 1, "a" is subdivision related to popularity/fame)
1969B = second album released in 1969 (I use custom field as tag equivalent because of numerical field limitation)
There is a lot more to it (including some folder ID enhancements), too much to explain out - but that is gist of just the folder structure.
I'm currently working on a whole new set of tag IDs.
I try to balance the complexity/over excess of the structure with simplicity by refraining from including too much. I've tried several different approaches,
but you can only get so much info in with the folder structure, whereas you really don't have to sacrifice inside the program.
It such a relative thing, it's difficult to say what the advantage is "over" the methods of other users. If file type (like flac) is uppermost important to you,
then that's what you go with. For me, that would be too limiting. I want to browse through with files in a folder by genre (mood, intensity, style). I care
about quality, but if I only have an album or songs in mp3 as opposed to flac, it's not going to kill the mood for what I want to listen to. For me, quality,
although "highly" important, will always be secondary to just craving a certain genre/artist/album (unless it's a very poor quality).
That's probably not the reason you use extension first. I'm sure you've got some good reason that works best for you. But I've never felt the need to put extension
as uppermost importance within Music. If I want to divide by extension, I'll do that inside MM.
I've also abandoned various "Letter" range approaches like "A - C", or single letter. It just adds too many, either top level or second level, folders to an already
well divided folder rich top level scheme. I like that currently each path is only 3 deep, but still includes a lot of info. The way my scheme is I get everything
ordered by the letter of the band "and" within the genre's letters; all in a single
folder. The only thing I might add in the future is
a little more info to the filename. I've done that some before, not all that crazy about it.
What's included in the structure is always a compromise for one's needs. Otherwise, it gets ridiculous the more you include. Now, tag IDs - that's
a whole other world of expansion and possibilities. But, even those, if not using an "abbreviated" system, can get out of hand as well.