Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: An idea for future foo ... (Read 5193 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

An idea for future foo ...

this is an idea that i had that i want to post and see what people think ...

it's for a new playlist format ... an XML-based one.

why XML, because you can say so much more with one entry.  also as i'll mention later specific tags could be sought out by specific plugins, telling the plugin how to behave when a certain song plays.

example entry:
Code: [Select]
// entry for a song
<song index="order that it would appear in the playlist" src="path/filename.ext">
// entry for info pertaining to the play of the song ... plugins use this to gather how they behave ...
// this is for the visulization plugin ...
<visualization src="this could be used to open a specific viz, or left out to use default" bgcolor="#" litecolor="#" medcolor="#" />
// these color entries would be specific colors the plugin uses, so one song could be red, another blue, etc.

// this is an entry for the crossfader
<mixer index="the point (in seconds) when the crossfader kicks in, you can now pinpoint when it kicks" in="value 0 to 100 used to tell how much incoming song fades" length="length of fade on both songs" out="value 0 to 100 used to tell how much current song fades" />

// and etc.

</song>


there could be other entires like for RG values, album art, buttons, throbbers, etc.  and all plugins should have to gather info from here before they go to there personal configs.

just an idea ... let me know what you think.

An idea for future foo ...

Reply #1 –
I like the idea! Thumbs up!

XML is a good thing and there's no reason not to support it. On the other hand I don't think it's a priority goal to implement XML in foobar (it works quite well without it ), but I'm sure a XML plugin will be there sooner or later.

As a healthy alternative to tags and other playlists it could be the music database format of the future.

BTW zick: you should mention some keywords in your thread's topic title or description. maybe write "let me know what you think about XML support" instead. It's easier for us to see what your idea is,  otherwise such threads get overlooked very easily.

An idea for future foo ...

Reply #2 –
Mildy off topic...

I don't think this has changed, but if it has let me know.  The only thing keeping me from using the foobar2000 playlist format is that it doesn't relatively ddress files (it uses the whole address of a file).  I don't know if there's a specific reason for this, but if I want to move my music collection (i.e. like to another drive) this means I've got to recreate all the playlists which is a pain.

An idea for future foo ...

Reply #3 –
Quote
(...snip...) but if I want to move my music collection (i.e. like to another drive) this means I've got to recreate all the playlists which is a pain.


If you have a good and unicode capable text editor you can just open the playlist and use search/replace function to change the filepaths. At least I have got this working and it is not too much hassle....
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

An idea for future foo ...

Reply #4 –
Couldn't you move them with the Rename files functionality of the Masstagger?

An idea for future foo ...

Reply #5 –
That is generally a very good idea. XML has a good structure so you could do things like:

Code: [Select]
<Artist>
    <Album1>
        <Track1>
         etc...
    </Album1>
    <Album2>
etc... etc...


If you really liked to get down and dirty with your playlists, there is quite a lot that you could do with an XML based playlist.

The only thing is, the current playlist formatting lends some interesting coding. I'm not sure how well all of this would translate to XML. I imagine switching entirely to XML would cause some people to stop upgrading their versions of foobar2000 and stick to older versions. Then again maybe I am wrong.

Me though I like the idea of XML playlist formatting...hmm I wonder if there is a player out there that does this already...?

An idea for future foo ...

Reply #6 –
it's not really about "supporting" XML ... it's more a matter of "using" it  at least that's what i think, and i could be wrong (and usually am).  using XML to "list" out the songs to be played and how plugins should behave during that song, shouldn't be rocket science, it's more a matter of compliance and standards.  building a standard that plugins should adhere to!  it's just like the web, there are these standards that are sticking points, but not everyone (like 95%) follows them.

back in the day when null$oft was hyping winamp 3 development, they mentioned an XML-based playlist that offered somewhat of the same functionality ... i'm mentioning this because in the day it sounded cool.  the ability to control plugins via a playlist was such a fabulous idea with incredible merit.  when i read about it, i was like, "why didn't they think of that sooner!"

right now the *.fpl format is somewhat ambiguous ... it's like i need a hex editor just to edit the playlist.  i understand the proprietariness of this but why not make it something that humanly readable and easy to change.

kl33per, something that i'd propose for the format would include an entry for a %musicroot%, that could be changed relatively easily.  all file entries in the list would be relative to this root.  thus moving files would be a snap.

if people like this idea ... maybe i'll use this thread to build a kinda document model, and then let you, the teaming masses, pick my brain, criticize/praise and offer suggestions.  what say ye!?

An idea for future foo ...

Reply #7 –
Quote
if people like this idea ... maybe i'll use this thread to build a kinda document model, and then let you, the teaming masses, pick my brain, criticize/praise and offer suggestions.  what say ye!?

Well your idea is a relatively good one. There is really only one issue that I can see. Whether or not Peter will implement this in foobar2000. Unless you believe this could all be achieved via a plugin? And even then who would want to code such a plugin? I imagine implementation would take a little while.

Either way, I don't see a reason not to discuss features. It could lead to some interesting developments.

An idea for future foo ...

Reply #8 –
yeah, a plugin for this implementation would be a bear ... i don't think that's the way to go about it.  if Peter reads the forums, like i think he does, maybe noticing a thread thats active might get his noodle going.  you know, give him some ideas.

if we pretty much layout a document model here, that'll leave out a lot of the guess work.  Peter will already see what people want.

An idea for future foo ...

Reply #9 –
Quote
null$oft

Nullsoft was never out to take your money.  This isn't Microsoft.  Even then, I think using "$" instead of an "S" is silly.

An idea for future foo ...

Reply #10 –
Quote
Quote
if people like this idea ... maybe i'll use this thread to build a kinda document model, and then let you, the teaming masses, pick my brain, criticize/praise and offer suggestions.  what say ye!?

Well your idea is a relatively good one. There is really only one issue that I can see. Whether or not Peter will implement this in foobar2000. Unless you believe this could all be achieved via a plugin? And even then who would want to code such a plugin? I imagine implementation would take a little while.

Either way, I don't see a reason not to discuss features. It could lead to some interesting developments.

The other issues with XML are speed and memory usage. I've used many DOMs, including the MSXML one, and generally the XML processing was the slowest bit of the system, including in one project where programmatically creating PDF files was even faster.

My playlist has 25000 tunes on it, I would have no idea how long this would take to read. I know SAX is more suited to this, and uses less memory, but it'd make playlist updating even slower.

sean

EDIT: However, an 'export to xml' function might be useful. As well as an 'import from xml' function, too

An idea for future foo ...

Reply #11 –
Quote
Quote
null$oft

Nullsoft was never out to take your money.  This isn't Microsoft.  Even then, I think using "$" instead of an "S" is silly.

Agreed. That's childish Slashdot style tactics.

An idea for future foo ...

Reply #12 –
sorry about the "$" ...

i used it in reference to the fact that they are now owned by AOL and are in the business of making money ... back in the day, they were the coolest!  agreed, money wasn't an issue, maybe almost the opposite of that.

i used to praise winamp; but since i found foobar, i've never looked back.

An idea for future foo ...

Reply #13 –
seanyseansean:

you mention SAX, is that an XML variant?  the name rings a bell, but i can't place it for the life of me.

do you think it'd be better to use that as opposed to XML?

in all honesty, speed is preferred.  if we could use plain-text parsing, and still offer variables to plugins, i wouldn't care!  i'm not saying XML is the only way to go ... i'm open to your critiques.

An idea for future foo ...

Reply #14 –
Quote
i used it in reference to the fact that they are now owned by AOL and are in the business of making money

If they were, why would they offer a free version?

The Pro version costs money to cover the costs of licensing an MP3 encoder, and various other costly additions they've coded into the player. foobar2000 gets around that by having a standard CLI encoder plugin which will allow it to use any encoder. That way, the onus of licensing fees is on the end-user.

I'd say it's more like Nullsoft is a parasitic being hanging onto AOL. AOL keeps them around for the image of the Winamp brand. This way they can also package the player with AOL for use. These tactics remind me a lot of the dot-com boom, and I don't know how long AOL will let Nullsoft live happily. They've already axed Mozilla, but WA has a much smaller dev team.

Well, I'm way off topic now, so I'll stop. 

An idea for future foo ...

Reply #15 –
Quote
If you have a good and unicode capable text editor you can just open the playlist and use search/replace function to change the filepaths. At least I have got this working and it is not too much hassle....

That would be painful for 400+ playlists.

Quote
Couldn't you move them with the Rename files functionality of the Masstagger?

Again, I would have to do this for every playlist.  Using m3u8 playlists, I can pick my entire music folder up from F: and move on to E: and everything will still work perfectly.  No worries, no hassle.

Quote
kl33per, something that i'd propose for the format would include an entry for a %musicroot%, that could be changed relatively easily. all file entries in the list would be relative to this root. thus moving files would be a snap.

I can see the uses of this if you wanted to move all the music files, but not the playlists for example.  As I keep all my playlists with my music, it would once again introduce more hassle for me.  Maybe if it was a selectable option, it would be useful.  If it was on by default, I'd still stick with m3u8.  The root should just be the location of the playlist file.

An idea for future foo ...

Reply #16 –
Quote
you mention SAX, is that an XML variant?  the name rings a bell, but i can't place it for the life of me.

From the sax webpage: "SAX is the Simple API for XML, originally a Java-only API."

SAX is more like a way to parse XML files "on the fly", processing them as you read them. Most XML parsers read the whole file into memory, then represent it as a tree of xml nodes. With SAX, you create content handler functions, and as the file is read, your functions are called.

For small amounts of data, there's no real difference between the two approaches, but for larger datasets, the SAX model has some real advantages.

An idea for future foo ...

Reply #17 –
Quote
Quote
you mention SAX, is that an XML variant?  the name rings a bell, but i can't place it for the life of me.

From the sax webpage: "SAX is the Simple API for XML, originally a Java-only API."

SAX is more like a way to parse XML files "on the fly", processing them as you read them. Most XML parsers read the whole file into memory, then represent it as a tree of xml nodes. With SAX, you create content handler functions, and as the file is read, your functions are called.

For small amounts of data, there's no real difference between the two approaches, but for larger datasets, the SAX model has some real advantages.

Foobar is already slow enough when searching a 25000+ mpc collection, i'm just not sure it's a good idea to use xml as a native format, as loading and searching it would be slower, and the memory usage would go up too.

SAX is the best way, but i'm still sure it'll slow the playlist functionality down too much.

I reckon adding an xml import/export to playlist facility is a good idea, though. Especially if it was formattable.

An idea for future foo ...

Reply #18 –
Couldn't you just use matroska for this? although it's a container format... It's XML based and open, right? or, if you want to make a new standard, you could build it on Matroska?

... Or maybe I have no idea what i'm talking about, and I missed your point completely

An idea for future foo ...

Reply #19 –
Quote
... Or maybe I have no idea what i'm talking about, and I missed your point completely

I think so.

An idea for future foo ...

Reply #20 –
you know what I want to see? foobar on an iriver. with mpc support.

An idea for future foo ...

Reply #21 –
Quote
Mildy off topic...

I don't think this has changed, but if it has let me know.  The only thing keeping me from using the foobar2000 playlist format is that it doesn't relatively ddress files (it uses the whole address of a file).  I don't know if there's a specific reason for this, but if I want to move my music collection (i.e. like to another drive) this means I've got to recreate all the playlists which is a pain.

I suspect it's because fpl playlists act as a quick substitute to the metadata database.

As a side note, you *could* use a scriptable editor, to edit 400 playlists with a single keypress, right?

An idea for future foo ...

Reply #22 –
Quote
Couldn't you just use matroska for this? although it's a container format... It's XML based and open, right? or, if you want to make a new standard, you could build it on Matroska?

I think you mean, base it on EBML, which is the Binary XML design that Matroska uses.  EBML is actually a seperate project and can be used completely independantly of Matroska. 

EBML would be good for being able to seek quickly through a file made with it instead of textual XML, and you also have the ability to easily store binary data in it.  However, in this case I don't see an immediate advantage to it.  I don't see any playlist being large enough for seeking to be an issue, and I don't know why you would need to store binary data in it.

@dr.zick:  Do you see any reason to use EBML?

An idea for future foo ...

Reply #23 –
i don't know enough about EBML and Matroska to really put my thumbs up or down ...

i do believe this thread has gotten out of control and off topic, though.  i could honestly care less about what format (eg. XML, SAX, EBML, plain text, binary, assembly) is used ... i mentioned XML in reference to what winamp said that they were going to do with their third release.

the point is to have a playlist that not only mentions what song will be played, but mentions how foobar reacts when that song is played.  each entry in the playlist should have a filename to be played, and a list of parameters to be passed to foobar itself as well as certain plugins.

i mentioned things like having 3 colors listed that would be used by whatever visualization you are running.  when a particular song is played, it's parameters include these colors that the viz obtains and uses.  another thing that i mentioned is a list of index points passed to the crossfader.  instead of it guessing when to kick in (whether it be based on volume levels or a specific amount of time until the end of the song), you can tell it exactly when to kick in and exactly what type of fade to use.  and these parameters can vary from song to song ... thus for one song the viz could use shades of blue, while another could use shades of red, etc.

and this is just the beginning ... if plugin developers adopt the practice of fetching parameters from playlists before a default config ... well the possibilities are in fact endless.

this seems to have become a war over formats, not the key issue at hand here.  sorry for telling it like it is ...


-dr.zick
don't shoot me, i'm just the messenger - Joey Pants