Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tunetyme]

I would like to try to develop a Wiki entry on how to set up the file folders for ease of use in MC.  There is no right way but we can develop a set of options for new users.  This is a post to a new user.


I believe that the essential element in database management is to try to create unique file folders.  On my music drive I keep 3 primary music folders. Rock (my largest collection), Jazz (next largest) and Music (with sub folders like country, classical, new age etc.).  I have over 3,000 artists and over 3,000 Albums and keeping this straight is essential for me. When you have a small number of files it is less important to develop a good structure.  All this adds a little work but it is very helpful when I am working with my folders in windows.  Because there are so many groups with "The" in front of their name I change it to "Rolling Stones, The".  If I didn't then the majority of my Group named folders would be under "T".  I also reverse names "Adams, Bryan".  Again this helps to keep files folder unique and easy to find.  When I Rip a disc I use the secure mode.

I do not have a separate file folder for various artists.  I rip them the same way I do albums and create a file folder for each artist\album\song title.  I don't add the track number to the song title as MC tracks all that info and is created in the tag unless it is a WAV file.  Again, this keeps all the tracks associated with a given artist in the same folder (Artist).  When I tried using other methods I had a difficult time with album art.  Some of this has been addressed with MC's ability to look up album art.  I used to keep various artist in a separate folder but as my collection grew it became a problem to maintain.  I also strive to make sure that all my song titles have each word capitalized. 

There are some great edit capabilities within MC that I use all the time.  Under tools\library tools\clean file properties: You can select which fields you want to operate on like Album, Artist. Artist (Auto), Album Artist, filename (name).  These are the ones I use all the time.  I can convert underscores to spaces, remove leading and trailing blanks, change spacing to single space, move articles to the end (I don't use this since I do it when I rip) and Fix capitalization Upper Case All Words.  When I import new music this is one of the first things that I run.  This is a great way to make all your files standardized.  If you are operating on a single file you can always use the Tag editor to make the changes you want. 

You can also use this feature to change the names of the actual files (filename (path)). Beware that this could cause some problems as this may create new folders and it will move the files to the new folder but it does not move album art if you store it in the file folder with the songs (I do).  So in that case you need to move the album art and delete the original file folder.  I don't use this tool very often, I prefer find and replace when I deal with the path filename.

Sometimes I have a problem with the tags as written by EAC.  In that case I can use (under library tools) fill properties from file name.  It will populate artist, album, and song title.  If you have a various artist folder this becomes very messy.

The tag editor is a very useful (under action window Tag) tool.  Under Filename you can edit the filepath song title and it will rename the song title (and it stays in the same file folder). 


Tunetyme 

[rick.ca]

I would like to try to develop a Wiki entry on how to set up the file folders for ease of use in MC.  There is no right way but we can develop a set of options for new users.  This is a post to a new user.

I believe you posted this elsewhere, and it's intended only to be "food for thought"—not the start of a wiki topic. It does illustrate how a seemingly simple question can blow up into something overwhelmingly complicated. For an introductory wiki topic, that obviously won't do.

The first thing a wiki topic should do is lay a firm foundation. The most important part of that would be to explain that MC is essentially a database application for managing media files in the file system and information about those files. Many new users have a difficult time breaking perceptions about how things work learned from other applications or personal experiences. They need to understand there is a 1:1 correspondence between the media files "imported" and entries in the database. From a database perspective, keeping track of the file locations is a trivial matter. MC doesn't care where they are and, to a large degree, any order in the file structure is irrelevant. There are good reasons for maintaining an orderly file structure, but those reasons are not likely to be found or understood without a basic understanding of what the database is and how it works.

If MC doesn't require any particular file structure, then what elements of the structure might be important and why? Following are a few that come to my mind. A good wiki topic would include all potentially important considerations so the reader could decide which are relevant to their situation and preferences.

• There are no absolutes here, but I'll start with the premise some degree of organization is necessary—even though MC can organize the collection without it. We could make a long list of the problems that one would likely face if all media files were dumped into one directory, or saved in an inconsistent folder structure. So...
  
  
• From a basic file organization point-of-view, things that are fundamentally different usually need to be organized differently and should be kept separate. In most situations, for example, the main media types (audio, image, video) would be in separate folders. That's probably equally true for some media sub-types as well (e.g., music vs. audio books, photos vs. art, movies vs. series). The same idea might also be applicable to genres (e.g., classical vs. popular music). To be clear, the point here is not that the items are different, it's that they are deliberately organized differently (i.e., the sub-folder structure is different). So, for example, classical music might be in a separate folder because it's organized by composer rather than artist.
  
  
• The file structure should support one's preferred or necessary work flows. Those will differ depending on media type and source (i.e., ripped vs. downloaded). In any case, you must specify where files go in the file system. They may as well be put somewhere that has meaning to MC. The most obvious (and essential) example of this is the import folder. MC is configured to watch specific folders for new media. Each such folder can be configured for specific media types so as to only import the files that are wanted. This is probably reason enough to have a separate import folder for each media type.
  
  
• Extending the "if you have to put it somewhere" idea, it might also be helpful to put media in sub-folders by media sub-type and/or genre. By configuring views that get this essential classification data directly from the file path, new media is automatically imported and classified so you know where to find it.
  
  
• MC logic for grouping tracks by album and determining whether or not those albums are complete does expect to find the tracks in one folder for the album. So, whether or not one cares about album groupings, putting albums in their own folder is helpful for maintaining data integrity. It follows that compilation albums would all be in an Artist folder named "Various Artists" or similar. Or maybe a few different ones, like "Compilations" and "Soundtracks."
  
  
• And something not to do: Include folders which make it more difficult to file something or find it later when outside MC. Prior to using MC, I was rather dependent on the file system for organizing my Rock music (the largest part of my collection), and therefore had the Rock genre subdivided (by sub-folder) into 11 different "Styles." Those styles, of course, are somewhat arbitrary, and therefore just make it more difficult for me to find things (usually when I'm adding a new album to an artist I already have). I haven't got around to changing it yet, but I'm sure I'd be much better off with all rock artists in one folder.

[tunetyme]

Rick.ca:

This is exactly what I am looking for.  The excerpt from another post was intended to define the topic not as a suggested entry.  Over the years I've seen a lot of questions about this and I know I've spent a lot of time rearranging file folders.  I don't think there is an absolute method but being able to present a few options and let the user select what makes sense to them.

For example, I do everything by artist\album including various artist CD's.  I can still find all the tracks easily by album name.  I use various artist CD as a means of introducing myself to new styles of music and artists.  If there is something I like then I start looking into the artist.  This method has opened a lot of new doors to music that I would not have known about.

I used to keep them in a Various Artist folder but I kept having problems with album art so I switched while my database was a tenth of what it is today.

A good explanation of files structure will go a long way toward an understanding of how MC works. 

If we can get some additional input on what needs to be included I am willing to take a pass at a rough draft.

Tunetyme   

[rick.ca]

Another important idea that should be conveyed clearly in an introductory wiki topic is one that has been expressed in recent discussions around this (MrC's comments come to mind). Generally, MC should be used to collect, edit and manage meta data about files. Initially, existing file structures and file tags may be an important source of information. But, ultimately, the objective should be to build a reliable, consistent database within MC. The tools provided by MC for doing so are generally more powerful and convenient than external alternatives. And once the information is effectively managed by MC, it can be written to physical file tags in the interest of security and portability, and the file structure can be managed directly by MC using the information in the database.

Point 6 of my last post is a good illustration of the idea. I can fix my folder structure (i.e., remove those useless "Style" folders) using ONE Rename, move and copy files operation in MC. The only reason I haven't done it yet is it doesn't matter much. I use MC to manage everything and rarely even look at my collection in my file manager.

[tunetyme]

I agree with everything you have said.  I've looked at so many different music programs programs and while some have some features I like, nothing can hold a candle to MC.  The database management capabilities is superior to everything I've looked at.  There are a few DJ oriented features I would like to see developed but that is a part of my wish list and right now I use a couple of other programs to do that.

I think a short introductory narrative about what a database is and the power of MC would be helpful to provide a framework for understanding what the program does.  This should be pretty basic.  I've been using MC since the release of 12 and I am still discovering all the capabilities of MC.  I think this will be a great exercise to learn more about MC's capabilities.

I must admit I am not a technical writer but with every one's comments I think we could develop a good document.

Tunetyme 

[Frobozz]

A little explanation of the database and how it is separate from the physical file structure on disc would be good.  For example, people who have been using Foobar2000 tend to think of things in a very file and directory based way since that is how Foobar does things.  People switching from Foobar to Media Center might need a bit of a hint to start thinking in a database based way rather than a file based way.

Might also want to include some general ideas of what kind of things people can do to organize the files and directories.

For example.  I have lots of classical music.  The track names from some classical pieces can get really long.  Long enough that if you try copying a directory to a FAT32 thumb drive you might run into pathname length limits because the pathname or filename is too long.  So I have a naming scheme that attempts to keep the track names short enough.

My current filename rule is:
Mid([Album Artist (auto)],0,20)-Mid([Album],0,20)-If(IsEmpty([Disc #],1),,PadNumber([Disc #],2))-PadNumber([Track #],2)-Mid([Name],0,20)

It's a bit complicated for someone new to MC.  But using expressions like Mid allow you to chop things down in a consistent and organized way.

I tend to change my directory and filename rules about every year or so.  Media Center makes it easy to do mass renames and moves.  It all depends on what I think at the time is a sensible way to organize things on disc.

[tunetyme]

Frobuzz:

You make some very good points.  I've run into that problem as well and it is not just an issue for thumb drives.  I've been thinking about ways to deal with it.  I have a lot of classical also and I remove the Virtuoso, Conductor, Symphony to other fields.  That has helped a lot.  I think Classical is a different kettle of fish and we need to address it independently as a category unto itself.  Another item that I plan to move to a different field is the Key it is played in.

Tunetyme   
 

[tunetyme]

Perhaps this topic would better fit the FAQ category.

[nickeaston]

Comment from a contrarian music curator having used MC... for about 10+ years...

I have never seen a need for me to use a "file structure"...I have a half-million tunes and manage my database with very little latency (in one folder called "Music").

I use a combination of Playlists, Tags, and the Custom Tags provided by MC; I'm thinking that many MC users aren't aware of all the available tags built into a music file, to say nothing of the infinite combination of custom library tags available in MC.  If I need some tunes in a specific folder, I use the old 'drag and drop' method; writing tunes to an external device is also easy (lately).

[Daydream]

May I point that with the exceptions of some of rick's comments you are discussing only music, music, music? Maybe you wanna change the title then? Otherwise if one adds videos, pictures, documents he most surely would think differently about file structures and the need for them.

[tunetyme]

Nickeaston

I agree that you can do everything within MC.  Over the years I have lost a MoBo, my music data drive and I have had some damage to my tags.  The objective is to provide a framework for some one who is looking for a logical structure.  If the structure is set up correctly then recovering from tag damage or damage to the MC files is relatively easy.  As I said the is no one right way but there is a method that helps new users.

[tunetyme]

Daydream

You are correct.  This needs to be expanded to include video and files as well.  Music is what I am most familiar with and I would hope others will help address both video and files.  I do have an extensive movie collection and the file structure is modeled in the same fashion that I have modeled my music.  I am confident that it could also apply to other files. 

The primary file folder is based on Genre such as rock, jazz, classical, etc. the next level is the artist or group. With classical I use composer. The next level is the album and finally a track listing.

The objective is to suggest a method of organization for new users.  This is not a hard and fast rule but it is designed to help.  I have revamp my file structure several times and it is very time consuming.

As I have said there is no one right way to do it.  Many people have set up a separate file structure for various artist Genre, Album, Artist, and track.  I choose to stay with the same file structure of Genre, Artist, Album, and track.  It takes a little longer on the front end but saves time later.

Tunetyme

[JustinChase]

I also pretty much have all my music in M:\ (Music) .  I do have a few subfolders currently, as I'm still trying to find the time to do some serious cleaning, but eventually I'll have all Music in that folder, with perhaps an Import folder.

I put the basics in the filename, store the tags in the files and MC backups the library so often that I don't worry too much about it.  I don't have to scan subfolders in windows explorer, it works for me.  This is usually sorted by default in most programs in a useful (to me) way...

[Artist] - [Album] - [Track #] - [Name] - [Genre]

It lets me forever restore the most important tags except in perhaps the worst of disasters.  I'm not saying this is the best way, but as was originally stated...

There is no right way but we can develop a set of options for new users.

Once you get used to using the database mindset with viewschemes, smartlists, etc, the file structure becomes a hindrance to me in regards to music.  I started using MC for music well before images and video were useful to me in MC, so I think about music very much in tags, so there's nothing I gain from layers of folders.

As was stated earlier, it's super easy to rearrange the file structure by using MC, but I don't want to have to dig thru folders looking for how I might have filed something long ago.  the fewer folders I have to traverse, the happier I usually am.

Other media types need that structure though, as it's harder to pinpoint the basic fields you'll always want/can search by.

Regarding Video, I'm using MC for everything but the actual recording of TV, and do have several subfolders in V:\ (Videos), including Movies, Documentary, etc.  Since rock solid video is a recent (much appreciated) development, I'm still using what I used for the other programs I used to use for Video and TV, etc.  I suppose once I have the time to really delve into theaterview setup/customization, I'll care much less about these subdirectories, and they may disappear one day too.

Regarding Images, I don't have them tagged well enough to use something similar to the above, it's mostly keywords, so no way to really have meaningful names that can be easily searched in windows explorer, so subfolders are a must for images.

I use this, for example, but I suppose it'll be hard to find a consensus on this

P:\traveling\mexico\estadodemexico\villaguerrero\totolmajac

I suppose the idea for me is *where* it was taken.  I suppose that's the easiest way for me to know where to start digging thru folders.  I'm sure other ways work well also.

Regarding Documents, I also have these in subfolders, but usually not more than one deep; Manuals, Health, Books, etc.  the search makes is fairly easy to find most stuff; mower, diet, etc is usually sufficient for the amount of documents I save.

[Daydream]

The way I see the difference between media types, and their corresponding needs for file structure goes like this:

- music has one and a half decade of proven track for using embedded tags. Because of that it is the least dependent on a file/folder structure. It can be stored as a complete mess file/folder-wise and still be able to have order, if it has tags, or if you can use various tools to identify it (digital fingerprint and whatnot). The moment you have tags and they are imported in MC, file/folder structure becomes irrelevant. With one Rename command and some expressions I can change the file folder structure n times a day and have no problems. So: a) well-documented tags and b) you can feed a mess to this media type (although not recommended) and still come up on top.

- video, until there is a revolution and every bloody container format is abandoned in favor of mkv (hehe), is nowhere near this. It's totally dependent on the file/folder structure. MC database and its tags and sidecar files are its own and true only in MC (move a video file to a portable player and you better have a useful name for it, it can't be @^!&^@#!.avi). At this point file/fodler structure rules 1) at initial import time when you bring your entire library in MC and 2) when you keep adding files from various external sources (not recorded TV). I.e. I DL tens of video clips every week, and every one of them has a different naming convention, 'cause_some_like_to_use_unix_names, or the date is mm/dd/yy or dd/mm/yyyy or whatever, there no two the same. For series, having some kind of structure to easily pick series name, season and episode order helps and so on.

- pictures are somewhat in middle, with MC still employing some particular solution in dealing with IPTC and that makes me use its abilities only half-way. ("Places"? That is the simplification of IPTC for Johnny Average?)

- documents I don't even know if any tags are retained (say, from pdf; cover support is still pending is some way or the other). Hence totally relying on file/folder structure.


Transitioning (or importing the first time) your music to MC it's the easiest of all media types. As with everything having an organized collection, with tags, helps. But then it doesn't matter, you can re-order, re-create, make folders with sub-folders by whatever criteria. It is the easiest mediatype to have the database populated with info. It's the easiest media type to write tags back to the files. Because of this combination you can't lose.
Transitioning other media types - not so easy. There are only partial tags, if any, to help. Then the file/folder structure rules.

[Daydream]

The primary file folder is based on Genre such as rock, jazz, classical, etc. the next level is the artist or group.

I'll debate this a bit if you're OK with it; a constructive debate, not really criticizing, after all all this choices are really subjective.

I'd say that [Genre] is not a criteria worth creating a file/folder structure by. Depending on where you get your metadata it may be different. Take R.E.M. since they just disbanded today. Allmusic has them as Pop/Rock for Genre. And only Alternative Pop/Rock, Jangle Pop, Alternative/Indie Rock, etc for Style. But I can list a dozen places where they are listed as Alternative Rock for Genre. See the problem? If I can't be sure of the designation, that field is not stable. I mass import new metadata from somewhere else, rename the music, and I'm gonna find the albums I don't know where on the hard-drive. Not good.

Artist name, album name, these don't change. Then...

[Daydream]

I use this, for example, but I suppose it'll be hard to find a consensus on this

P:\traveling\mexico\estadodemexico\villaguerrero\totolmajac

If you're a pro, you start tagging them by job number, sessions and other funny things like that . If it's for fun, a sound digital workflow it's still a very good habit. In my case, even if it's not a fair comparison, Lightroom habits win by far when it comes to archiving photos.

[MarkCoutinho]

@tunetyme Thumbs up for your intentions - I wish more people were like that. However, in this case I think it's not necessary: MC doesn't care where the files are stored.

[rick.ca]

However, in this case I think it's not necessary: MC doesn't care where the files are stored.

The fact "MC doesn't care where the files are stored" doesn't mean there's no need for organization in the file system. A number of important considerations were identified early in this topic. An experienced user may think these things are obvious, but they're exactly the sort of things many new users wonder about—or fail to consider.

[nickeaston]

It appears to me that if v2 tags are accidentally removed instead of v1 in a batch of files, under some or all conditions they are gone forever, not retrievable from the library database.  If this actually happens in MC, perhaps the "remove v2 tags" needs an "are you sure" confirmation for safety reasons.  Since I have several thousand tunes where the v2 tags have disappeared and the artist and name or the filename are newly written into the name tag, and if this not a 'remove' error on my part, I need to look elsewhere for pilot error to prevent further loss of tags.

Note:  I always remove v1 tags because I don't want the thumbnails, and for some reason  dumping v1 tags provides a little more accuracy in duping with DoubleKiller.

[tunetyme]

I really appreciate everyone's input. 

I realize that MC doesn't care what file structure you use.  As for Genre the thought is very broad like rock, jazz, classical, blues etc.  Within these I have dozens of "sub genre" like album rock, pop rock etc.  Many albums can fit into multiple sub genres.  For me there is rock, jazz, classical and other.  As one's collection grows (I have over 40k tracks) it helps to organize your data for many reasons.  I back up my music externally and I use some of my older, smaller discs as backup discs.  It allows me to back up a broad genre and take advantage of some discs that I would ordinarily discard.  One of the tools that I have used repeatedly is to fill in artist, album and track from the path.  This is very helpful when tags are damaged in MC and the file itself.  One of the reasons to break it down into major categories is you store the album art or any additional docs with the tracks and move it within MC then the jpeg and other files do not move nor is the old folder deleted.  There are times when we need to  cleanup the data.  When it is organized your search time is significantly reduced.

When dealing with any electronic media, S#*! happens.  There have been times when I have lost my media files (one complete loss) and had to rip them again.  In this case MC was able to repopulate the tags.  I have had my MC database corrupted as well and I can recreate from the tags.  I have also experienced having my tags damaged.  MC has so many great database management features and frankly it was the primary reason I originally bought MC so many years ago.

What I am trying to do is provide a framework for newbies who have very little database experience.  They have a need for a framework to understand the power of MC's database.  The simplest comparison and most obvious is an alphabetical file drawer.  Every method listed here is valid but the question is how do we educate a newbie? 

The second objective is to really discuss the power of the database tools within MC.  The "how to" section.  I think this will cut down on some of the repeated questions on the forum.  Think of it as a users manual for beginners.  As one becomes proficient in any skill they forget the challenges they had when the first started.  There is so much in MC I don't know how to use either because I am unaware of the feature or how to use it.  I have too many hours in building my media files to run the risk of damaging them, therefore I limit the risk associated with trying something new that I know nothing about.  I've screwed up plenty of times already.

Many, many years ago I did shell programing in Unix mainframes.  Since I understood what the data was and the format we needed the data in I was trained to write and test shell programs until they ran perfectly and then it was passed off to a C programer.  We would create a series of C subroutines to clean up what at the time was huge databases (70 -100Mb).  If you have ever looked at the cryptic Unix command descriptions you would be lost without training.  What I am suggesting is a 101 class for organizing the databases.  This will be a suggested method for newbies not a hard and fast set of rules.

One of the areas I would like to learn more about is using the command line tools in MC.  I don't have the time to try and figure it out on my own and the Wiki reminds me of the first days I was using Borne Shell.  It would be great if we could start collecting from users a list of the command line tools they use.  It would be so helpful to some one like me who hasn't programed anything for 25 years.

Tunetyme         

[rick.ca]

What I am trying to do is provide a framework for newbies who have very little database experience.  They have a need for a framework to understand the power of MC's database.  The simplest comparison and most obvious is an alphabetical file drawer.  Every method listed here is valid but the question is how do we educate a newbie?

A good place to start would be to make it perfectly clear the following are completely separate things:

• The structure of file pathnames in the file system.
• The organization of data about those files in the MC database.
• Data stored in file tags.

Only then can the implications be properly understood. For example...

• The MC "Library" is a database of files in the file system—"linked" by filename.
• The organization of data in the library is independent of that of the file system.
• If the file system is organized, the same data it's organized by can be extracted from the filenames and recorded in the library.
• MC reads/writes data from/to file tags. In most situations, it makes sense to allow it to do so (for whatever data one wants to record in the file tags)—in which case the data will appear to be identical. This is why fields in the database are commonly referred to as "tags." However...
• This linking of fields to tags can be set or disabled by field or globally.

More specifically, how files are best organized in the file system will depend on...

• The workflow used for adding new media to the collection (i.e., in what order will it be tagged, imported, moved?)
• The most convenient way to locate media directly in the file system (i.e., when necessary to do so outside MC). Depending on the workflow, this may be necessary when initially saving new media to the file system.
• Generally, the primary media types should be kept separate, as should sub-types that are fundamentally different (e.g., movies, series, home videos). This may also be the case where one chooses to organize something differently (e.g., classical music by composer\work rather than artist\album). In some cases, it may be purely a matter of preference (e.g., to separate documentaries from movies).

Hmm. It seems what I've said is pretty much the same as my first reply. Sorry to be redundant, but that was some time ago...

[tunetyme]

Rick.ca:

I want to try to keep this simple and just deal with the file structure on the hard disc.  You can populate a number of fields in MC based on the file structure itself.  I have found these features in MC a tremendous value.

I agree that a good write up about tags would be the next step and discussing some of the basics of how a database works.  My goal is to provide a framework upon which a new user can build.

I think the next step is to draft a write up for comments.  I will start working on that this weekend.