I'm wondering if there's a plugin available which enables users to export/copy there foobar db to or in a specific format.
E.g. I would like to export my playlist to an xml file.
I could configure the foobar copy command to do it but this won't be in a proper format if I do. This is because the copy command works on a line-by-line base. Therefor it's not possible to create e.g.:

If a plugin like this doesn't exist I might make this my first plugin project as soon as I've got some spare time again. It's probably not that difficult as far as I can see.
...unless someone is dying to have a plugin like this and is willing to make it for us of course
...or if the suggestion is too good and it will be included in the foobar core (atleast a default xml line-by-line export/save as option which can be reformated automaticly using xslt)

I think you could do this with plain title formating ("copy command"). There already are some "generate html playlist" formatting strings somewhere..

read this

Nice one mazy!

I'm interested in a bit more information though:
- What's the current status of the plugin?
- Where can I get the plugin?
- How customizable is the output? (I would like one big file containing all bands, all albums, all tracks, etc.)
- Will it export all file tag data of any file? (mp3, ogg, mpc, etc.)
- What's the exact output format concerning the xml tags and attributes? (from a symantic web point of view some tagnames might have to be altered to create an output which can be used in a wider area)

I could help out perfectioning it if you like, but like I said earlier, I have to get some other stuff done first (catching up some uni projects ).
It would be great if it can be used as a main foobar playlist format but in my opinion that would be something for a later stage.

it can do export / import, however i'm waiting for foosion to finish next version of foo_lua - and that won't happen anytime soon, as he works on other plugins with higher priority

it's not in state to be released for public atm

as it is now, you just select stuff in your playlist and then select the command / press shortcut to export / import. i made it to do that on directory basis, so every bunch of following items with the same directory gets one file in that dir. that could get changed in 'release' version. i think that whole database export / import could be added ....

yes, other than technical (i may change that in the future). atm i export / import only replaygain subset of technical tags

that may change. as it is now, it makes well-formatted xml files, however the tags subset is not (that is selectable in the config section of my script) fixed, i.e. if it can use some tag's name as xml entity without breaking the rest (for example it wouldn't use it for tag which is already used in other meaning like <xml>, <tags>, <tag>, <files>, <file> and <common>) it would use it. other ways to go are: 2) always use <tag> with attribute 'name' for every tag, or 3) allow limited subset of tags, i.e. basic tags, to be used without <tag>, like 'artis' etc. we have to discuss that. atm it can do any of these, by simply changing lists of valid and / or invalid tags (tags' names which can be used directly as an entity).

sure, we can share some ideas

yeah, i agree ... but that would need someone else to make it or at least simple code to call my script. it's possible that foosion would add some callbacks in the future though

you can see the three possible xml entity scenarios here: 1, 2, 3.

it shows off pretty well almost all cases of possible output files from xml side of things. only thing left is case of items with subsong - <file> entity then gets new attribute 'subsong' with that value.

you can't only select which tags to use directly as xml's entities - you can select which tags to export / import - using inclusions and / or exclusions lists.

I think you're loosing track a bit in the 2nd and 3th example.
Although I understand your intention using the <tag> tag with different names, although it's valid xml, goes against the xml idea. The tags are used to give the information contained a small logic description. The tag attributes should be considered more like meta data of that specific tag or tag group.

To overcome the breaking part if tags get stored as information, why not use the same trick you use in html? Using $#60; or &lt; for less-than and using $#62 or &gt; for greater-than. Instead of "<tag>" you will get "$#60;tag$#62;" or "&lt;tag&gt;".
I realize this requires a conversion again when displaying the information in e.g. foobar but this shouldn't realy be a problem and atleast your being consistent if it comes to possible web content. This way you can eliminate using the name attributes in an inconsistent way.

Some questions again:
- What do you mean by subsongs?
- What's this foo_lua plugin? I wasn't abel to find it on the plugins page but maybe I'm overlooking something.
- Why is your plugin depending on it?

i don't understand you well ... could you elaborate on it a little bit more? why should i use <tag> with attribute 'name'? valid names for xml's elements can't get substituted like that, regular expression for them in lua's convesions is: '^[_:%a][%w%-%._:]*$'.

i do substitutions on them when used as attribute values and similar substitution when used as text data between starting and closing element. so it can handle <, >, &, multiline, " (when used as attribute's value) etc.
aren't you familiar for example with '.cue' files? you can have something like one mp3 file with whole album and '.cue' with positions of it's subsongs ... foobar can understand that and make these items, using '.cue' file as source file, 'subsong' index to reference index of song in that file and 'referenced_file' to point at the big audio file.

plugin by foosion which isn't public / supported yet, however you can find it on the internet for playing with it. it makes it possible for lua scripts (lua is a programming language suitable for embedding in other programs - it's being used by foo_looks version 2 for example) to extend foobar and use subset of foobar's api

i guess that's obvious now - because it's lua script, not a regular plugin

so please provide me with more of your thoughts . i could of course do something like
however that seems a bit like an overkill to me ... i think that using attributes is perfectly ok. the problem is, that by forcing the use of <tag name=''>, you can easily provide scheme for that kind of xml. you can even do that when using fixed set of allowed tags to be used as elements, although that makes it a bit more complicated for third party programs to parse / write. i think that scenario 1) or 2) is best (you can get <tag name=''> even in the former). foosion would prefer 3) or maybe 2).

It seems I misunderstood your reason to use tag attributes like in example 2 and 3, sorry about that.
I still don't exactly understand why you have to use an attribute sceme like in example 2 and 3. My eye's always start to spin looking at regular expressions
As far as I understand it it's not possible because you make use of the foo_lua plugin and that plugin just isn't capable of using a different sceme?

I am (although I rarely use it), I didn't know you where refering to them by using the term "subsongs".
I though you where pointing at songs which consist of multiple parts. Sometimes artists give a song a main name and specify the names of the different part in the song as well.
From an plain export point of view you wouldn't get in trouble just listing the song names and length if it comes to getting an output of all the songs and albums you have. If you want to use the exported xml file to be imported again and use it as a playlist then it will cause problems. To get around this you could specify the start and endtime of each song and include the same file name for each of those songs. In my opinion it's up to the player to do the interpretation and checking of this.

Like I sead before I'm looking at it from a clean output point of view and how it can be tranformed/understood the best and easiest way possible.
The tag itself should be the name of that tag. Not like in example 2 and 3 where you specify the name of the tags using the name attribute. Although it's valid xml it goes against the idea of xml.
In my opinion a sceme like in my first post or in your 1st example would be the best thing to do. Otherwise you might as well give an extreme output like:

i guess you're missing something, no offense. i think i've made it clear ... anyway:

1) xml's elements can have names starting with underscore, ':' or a letter. other characters can be any of these plus digits, '-' and '.'. you can't do any substitutions on them, that's possible only for attributes' values and text enclosed between pair of matching tags.

2) concerning that 'goes against the idea of xml' issue, well you're not correct. please re-read my previous posts. xml files of specific structure should have scheme - an afaik that means finite / enumerated set of elements' names.

3) i can output any style i want, lua is turing-complete and it's real programming / scripting language (maybe with limited basic usability because of libraries etc., but in the end - that's lua's philosophy).

4) subsong / cue handling is fine as it is now. foobar uses that approach. of course the way i'm doing it atm it's not self-contained - you would still need the .cue file.

--

what we should discuss is which scheme i gave we should use. and then other issues like how it should look like when exporting multiple folders / albums in one file etc.

Ok, got it now, finally, sorry for the delay. I didn't take xml invalid music file tag names in acount. I didn't know tag names for music files where allowed that open.


I didn't say it was invalid xml but the element name itself should provide the description of the contained information. That's how the xml structure is intended to be used.
In our case because of the possible invalid element names that might occur we have no other option but the use of a scheme like in example 2 shouldn't be promoted as long as it can be avoided.

I'm wondering how big the risk is of getting invalid tag names. As far as I know most tags will have valid names by default (atleast the ones I came across). Therefor I still think we should stick to the first scheme and make the attribute exception for the tags that where created by the people who wheren't thinking clear
At export we could also provide an option to enable or disable the use of attributes. If an invalid name pops up it will be excluded from export (or maybe renamed). This will also help getting rid of those tags in music files because in my opinion those tags shouldn't be named like that in the first place (atleast, not anymore).

I was thinking of using our own names for each tag field and providing a comparison chart to convert each element name to the tag name based on it's music format. Though this will be a pain in the ass because you can't take each possibility in to acount we could do this partially for all the main tag names. Therefor using the actual tag name incase it's not included in the chart. This way we will have a more fixed xml structure being more compatible with other applications instead of basing each element name on the tag name. The comparison chart would only be used at moment of export and if the xml file is going to be used as playlist somehow.
What's your view on this?

I also think we should introduce a namespace for the xml tags to prevent any incompatibility with other documents.

I think we can't provide a relative linking to the file names, therefor we probably have to specify the complete path for each single file. Using the possible element structure for the location if it comes to directories will cause too much problems/exceptions. We could provide an option to make the playlist relative or not but than the playlist, if relative, always has to stay in the same location.

I'm still playing about with the structure for the multiple folders/albums export. More on this in the near future.

yes i agree with you. i have included all the possible ways to handle all metadata that could occur - of course using tag names which couldn't get used as xml's elements is bad idea - however alphanumeric tag names with spaces are quite common. one example: 'album artist'.

conversion scheme could help with this, however i think it would be just an overkill. users using simple names for tags would get simple / nicer document.

we need imput from others ...

The reason I mentioned this was because of the different names for the same kind of tag in different audio formats. E.g. for the url "wwwuser" is used in id3v2 tags but simply "url" is used in ogg tags. To convert this to one xml tag name it will be easier for other programs to know what to do with a certain tag.
I agree with you, it doesn't make implementation of the import/export function any easier.

As for the multiple folders/albums export, I came to the conclusion we have to eighter "force" people to create a consistent directory structure and naming scheme of their music files and provide one or two export options based on those formats or we have to provide all the information for each track individually in the xml file. In the second case it's up to other applications to group all the information.
The question is, do we want to base the export only on the naming scheme, directory scheme or a combination of both?

In the first case, if "forced", only than we can export a scheme like example 1 and in my first post as an extension to that.

2 cents of a friend of mine:
The scheme should be directory independent. What about path in front of the album as an attribute and the filename in front of the tracks as an attribute. In case of a deviation the filename could be relative from the albumpath.
I agree with the creation of our own tags and not just copying every single tag name. Maybe there's already an xml standard for music info otherwise we could use the rdf standard to create out own.

I was already thinking of rdf as well, how do you think about it?

sorry for that much delayed reply.

what is rdf exactly?

RDF is an Resource Description Framework - a metadata standard. Read more on W3C, or do a google search

np, it got me to stay focus on more important work, so in a way it was a possitive thing
Its not that we have to hurry anyway

RDF is a "new" XML based recommendation created by the W3C.


While we are at designing an xml format anyway, we might as well do it right by creating an RDF/XML file for the playlist export/import. This way the information will be structured in a more uniform way so it can be interpreted by different applications easily.
It will still be an XML file but now set tag names (RDF namespaces) will be used for the information structure and as an addition we add our own namespaces and tag names which we where going to do anyway.

We're still at a point we have to get some more people as well, unless nobody's interested in having an xml based export/import function in the first place.

I still think a fixed set of tag names is the best thing to do. Although it's more of a hassle to implement it will provide a cleaner output for general use.
The problem is, I don't know how this could be realized the best way possible, I don't know the options we might have.

Remember that users can create arbitrary tag names in fb2k, so tag names are data as well. If you restrict the range of possible tag names in your design, it will be useless for some people - at least for purposes like database backup and such.

Just my 2 cents.

Maybe a configurable hierarchy of fixed tags, with all other data stored at the deepest level?

That's why I suggested a comparison chart to overcome the differences between the default tag names in the different audio (tag) formats. This way e.g. the element <uri> can be used for the storage for the URL tag of ogg files and WWWUSER id3v1/2 tag of mp3 files. By refering to the chart <uri> will be linked to the specific tag name bepending on the tag format.
In this case arbitrary tag names always have to be included separately, like kode54 is refering to (I think). A separate section can be created for this in the xml file. The safest way to do this would be on a file level but a check could also be included which places this data on an album level if the info is exactly the same for a complete album.

To get the different element names and tags names from the chart linked together properly, the original tag type name has to be included for each file (or again, on a album level is consistent).
Something that could also be done is include the original tag name for each element name in the xml file as e.g. an attribute. This will eliminate the use of a separate chart at import but a chart still has to be used at export to determine what tag we are talking about.


In what way or to what extend do you mean configurable?

We can always include an extra option to export all tags purely on a tag name basis if people aren't interested in a consistent output if it comes to xml element names.

Maybe an example of the combination of the rdf structure in the xml output would be in place.
Supose we started using the namespace "pl" (playlist).
The namespaces for rdf tags are "rdf" and "rdfs"
The xml output might look like:

As you can see I'm making use of rdf tags where they are in place because of the purpose they have.
For the tags that aren't defined in the rdf specs we use our own tags.

Such as: year, artist, album, title. Everything else goes into a list under title. Of course, then you have also have to create generic categories under each level. Under title, tracks without title tags. Under album, titles without album tags. (and underneath that album group, files without title tags.) Then, under artist, a category for missing artist tag. (with underlying missing X groups as well) Then, under year, group for files without year information.

Also, configurable dynamic generation of certain categories. For example, if there is no "year" tag, find the year from the "date" tag if possible. Of course, I'm not sure if its possible to pick out the largest single number in the "date" tag that's >= 32, then expand it to four digits if necessary, in Tagz code. Of course, we're talking about LUA, aren't we?

Plus, if you generate data, like with "year" above, you'll want to mark any files that required generation so you (optionally) don't add that data to the database on the way back in.

The idea of automatic data generation in this case is for organizational purposes.

well kode54, for data guessing, i have 'tag guesser' lua script, so i wanted to keep tags export / import code as clean as possible