Skip to main content

Topic: Metdata Integrity (Read 6166 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Metdata Integrity
I'm becoming increasingly concerned with the integrity of my metadata, and all the talk about "changing files every time you play them is bad" is getting to me.  I'd like to keep everything that isn't inherent to the song in the DB, but also be sure that all the information relevant to the song is stored within the file itself.

As a possible solution: would setting foobar to write ID3v1 tags only do what I desire?  I'm thinking this will work because ID3v1 only has so many fields, so %play_counter% and %rating% will be restricted to the DB, but if I realize that my %album% field had a typo in it, any changes I make will be reflected within the file in addition to the DB.  Am I correct in thinking this?  How am I even able to tell whether metadata is in the file or just the DB?

  • banjobacon
  • [*][*]
Metdata Integrity
Reply #1
There was a request for a plugin which would allow you to choose which tags would be writtern only in the db, so %play counter% and other related tags would stay out of the file. Would that satisfy your needs?

I don't think anyone is working on it, though.

  • jkwarras
  • [*][*][*][*][*]
Metdata Integrity
Reply #2
Quote
I don't think anyone is working on it, though.
[a href="index.php?act=findpost&pid=271645"][{POST_SNAPBACK}][/a]

I was the one who requested it last time I think
I would love that kind of plugin/feature, it's the only thing I miss in fb2k.

  • ElBooto
  • [*]
Metdata Integrity
Reply #3
I'm not sure if your soultion would work or not. You could easily experiment to find out tho...

I agree with the "don't update the file all the time" crew and here's what I do. My music is stored on a fileserver with read only permissions. I have a "check in" directory for new music and make sure it's all tagged properly before it goes into the main music directory.  If I do find that I need to alter some tags then I log into the fileserver and fix them there (where the account has read/write access to the files).  This works OK, but certainly there are extra steps involved, so it might be too ugly a solution for many.

What you could do on a single workstation (provided you're not running 9x/ME) is set up multiple accounts, one that has read/write access to the files, and your normal account which has read-only access. You could then either log in/fast user switch (in XP)/use run-as or whatever and load another foobar instance under the credentials of your read/write account when you want to update the files.



Quote
How am I even able to tell whether metadata is in the file or just the DB?
[a href="index.php?act=findpost&pid=271628"][{POST_SNAPBACK}][/a]


This is a very interesting question. I'd really like to know if there is a way too.
  • Last Edit: 07 February, 2005, 08:07:36 PM by ElBooto

  • jkwarras
  • [*][*][*][*][*]
Metdata Integrity
Reply #4
Quote
This is a very interesting question. I'd really like to know if there is a way too.[a href="index.php?act=findpost&pid=271691"][{POST_SNAPBACK}][/a]

Actually the only way it's to check it outside fb2k, with something like 'tagger', to see what tags are really written into the file.

I did request the possibility of having different colours in the infobox for tags in the DB and tags in the file, but apparently this can't be done within the actual SDK, dunno...
  • Last Edit: 08 February, 2005, 04:22:07 AM by foosion

  • Olive
  • [*][*][*][*]
  • Members (Donating)
Metdata Integrity
Reply #5
Yes that would be cool, instead of the "block tag update" checkbox there was a text box where we could specify a comma-separated list of metadata fields not to be tagged (* to block all). I'm not 100% sure this could be achieved by a component though, rather a feature request for version 0.9

  • saratoga
  • [*][*][*][*][*]
Metdata Integrity
Reply #6
Quote
There was a request for a plugin which would allow you to choose which tags would be writtern only in the db, so %play counter% and other related tags would stay out of the file. Would that satisfy your needs?

I don't think anyone is working on it, though.
[a href="index.php?act=findpost&pid=271645"][{POST_SNAPBACK}][/a]


AFAIK the playcounter plugin allows you to set it to only write to the database.

Metdata Integrity
Reply #7
Quote
Quote
There was a request for a plugin which would allow you to choose which tags would be writtern only in the db, so %play counter% and other related tags would stay out of the file. Would that satisfy your needs?

I don't think anyone is working on it, though.
[a href="index.php?act=findpost&pid=271645"][{POST_SNAPBACK}][/a]


AFAIK the playcounter plugin allows you to set it to only write to the database.
[a href="index.php?act=findpost&pid=271972"][{POST_SNAPBACK}][/a]


Only when they're first written.  If you ever update a file's tags after that, the %play_counter% tag will be written to the file as well.

Metdata Integrity
Reply #8
Quote
There was a request for a plugin which would allow you to choose which tags would be writtern only in the db, so %play counter% and other related tags would stay out of the file. Would that satisfy your needs?

I don't think anyone is working on it, though.
[a href="index.php?act=findpost&pid=271645"][{POST_SNAPBACK}][/a]


That would be so, so awesome.  Is it a member of the set of all possible plugins? 

  • gob
  • [*][*][*][*]
Metdata Integrity
Reply #9
Right now i have all of my rating, play counter, and etc. stored in tags. is there a way for me to transfer these values to the database and delete the tags? i really dont like storing this info in the files.

  • mazy
  • [*][*][*][*][*]
Metdata Integrity
Reply #10
Quote
Right now i have all of my rating, play counter, and etc. stored in tags. is there a way for me to transfer these values to the database and delete the tags? i really dont like storing this info in the files.
[a href="index.php?act=findpost&pid=272730"][{POST_SNAPBACK}][/a]

that's not really possible atm. my repost from another forum:
Quote
... you would need changes in the core for that and that's what i hope for in 0.9 ...

the only thing (or two) i can think off would be this hack-ish approach:

1) block all tag operations and make plugin, which would monitor changes to db (not sure there's a callback for that - that's the problem) and propagate changes to some 'allowed' tags to the files. there would be these problems:
1.1) not sure there's a callback for db change
1.2) plugin would have to handle writing of the tags itself (for all formats of files, all formats of tags etc.)
1.3) there could be issues as how to read these tags back etc. (my scenario: plugin would update the file, foobar would notice that because of timestamp or filesize change and re-read these tags back from file to db, deleting all extra-db tags)
1.4) other problems

2) make plugin that would provide service to others to read / write tags for given metadb handle from external db (mysql, txt, whatever ...). problems:
2.1) plugins would have to be updated to support this
2.2) there could be overkill (i.e. mysql would have to be instaled etc.)

so as much as i would love this, it's something we better have to wait for to be addressed in the core ...
info about my tag guesser script for foo_lua (preview version available):
http://www.hydrogenaudio.org/index.php?showtopic=16987

  • gob
  • [*][*][*][*]
Metdata Integrity
Reply #11
i wonder if the current database will be compatable with future foobar versions..

  • mazy
  • [*][*][*][*][*]
Metdata Integrity
Reply #12
i wouldn't be surprised if not ... iirc that has happend before.

not a big deal though, is it?
info about my tag guesser script for foo_lua (preview version available):
http://www.hydrogenaudio.org/index.php?showtopic=16987

  • gfngfgf
  • [*][*][*][*][*]
Metdata Integrity
Reply #13
Quote
i wouldn't be surprised if not ... iirc that has happend before.

not a big deal though, is it?
[a href="index.php?act=findpost&pid=273003"][{POST_SNAPBACK}][/a]


I'd say it is if you don't write tags to your files (ie, keep them in the database only).