INTERACT FORUM

More => Old Versions => Media Center 12 (Development Ended) => Topic started by: broncodan on February 06, 2007, 10:55:19 am

Title: storing library data in tags - good or bad?
Post by: broncodan on February 06, 2007, 10:55:19 am
Hi all,

I only keep the standard items in my actual file tags (idv3 2) - artist, album, track , year, etc.

I have all types of other information that is actually in my MC library - lyrics, ratings, etc

Is there an advantage or disadvantage to having all the extra data in the tags?  I am contemplating doing this but wasn't sure one way or the other. 

Any opinions/advice/comments?
Title: Re: storing library data in tags - good or bad?
Post by: Mastiff on February 06, 2007, 12:15:01 pm
I only keep the most basic tags, Artist, album, name, track number and genre, in the files. The problem with having more there is that the files will change every time you change that info in any way, and it's a pain in the you-know-what for backup purposes.
Title: Re: storing library data in tags - good or bad?
Post by: glynor on February 06, 2007, 12:21:40 pm
I take the other tack.  I store basically everything MC can in the file tags.

It does have the effect Mastiff explained, but that doesn't really bother me.  My backup procedures could certainly be more robust, but I basically just make full replicas every so often (no incremental stuff), so I don't really care.

Storing as many tags as possible in the files themselves makes moving files around between different computers (of which I use a ton) a lot easier.  That's more important to me than the incremental backup stuff.
Title: Re: storing library data in tags - good or bad?
Post by: AustinBike on February 06, 2007, 01:18:00 pm
Store in the tags, then they are portable to any system. I use JR at home, an ipod on the go,  and who knows what work will let me use (or block).

Tags are the best way. But for some stupid reason MC thinks that "year" is a non-standard field.  Haven't figured out how to fix that yet.
Title: Re: storing library data in tags - good or bad?
Post by: John Gateley on February 06, 2007, 02:30:04 pm
Store in the tags. I moved my files to a new machine (and a new library) recently and lost all my custom fields.

j
Title: Re: storing library data in tags - good or bad?
Post by: jkrzok on February 06, 2007, 10:36:34 pm
Does anyone know of any software or hardware that will choke on non-standard tags?
Title: Re: storing library data in tags - good or bad?
Post by: slipknot on February 06, 2007, 11:39:40 pm
I take the other tack.  I store basically everything MC can in the file tags.

It does have the effect Mastiff explained, but that doesn't really bother me.  My backup procedures could certainly be more robust, but I basically just make full replicas every so often (no incremental stuff), so I don't really care.

Storing as many tags as possible in the files themselves makes moving files around between different computers (of which I use a ton) a lot easier.  That's more important to me than the incremental backup stuff.

My method too, works great for me.  No retagging is ever necessary when moving files around.
Title: Re: storing library data in tags - good or bad?
Post by: hit_ny on February 07, 2007, 03:31:23 pm
So it appears if you keep things in one place then you can have robust faster backups, file checksums etc.

So i only store the most basic tags in the files and then never touch them again. Absolutely no tag updates allowed once files are imported into MC. Not like any other app can read any of MCs internal tags anyway. This has the added benefit that MC is a lot faster on the P3 that i run it on.

Of course then you have to be rather careful with your MC library files, frequent backups etc. I would not advise to do this until you are comfortable with MC.
Title: Re: storing library data in tags - good or bad?
Post by: John Gateley on February 07, 2007, 04:06:20 pm
Anyone feel like condensing this info and adding it to the wiki? The tagging section is one of the least complete and could use some attention.

Thanks,

j