next »

[uRRada]

Please clarify what you mean by "with additional colomns etc".

Maybe "type", "number of songs", "estimated time of all songs in playlist", etc.

But actually, as to me, I don't need any. -))

you dont need them, why do you ask for them??

total/curent song number and total playlist time is shown as usual, check the top of the pic.

I didn't ask. Xmplay is perfect! You are asking... )))

I just made a suggetion for playlists that could help to keep xmplay minimum size.
I am against overloading xmplay for doubtable exrtra features.

[Pike84]

Yeah, as fernsx suggested, the artist/track info wouldn't necessarily have to be retrieved from the tags. In my case, just taking them from filenames would work fine, and I suppose most people have artist and tracknames in their filenames and/or folder names too. Then only the order/place of these elements would have to be defined (by the user).

[edit]
Well, I guess this might make the process a bit easier: There's this masstagger program, GodFather, that uses a very nice way of gathering tag info from filenames and folder names. It divides them into different parts, called tokens, that are separated from each other by user defined separators.

An example will explain this most easily: Lets say I have a music file in X:\artist - albumname\track# - artist - trackname.mpc. The '-'s are separators, so if I wanted to see this in form "%artist - %trackname", I'd tell XMPlay to use token 2 and token 3 from the filename. In Godfather style it would be "Artist:%F2 and Title:%F3". If I also wanted to grab the album's name from the folder, it would be %D2. This way it would be easy to define different parts of the folder- and filenames to use in playlist formatting.

[Torkell]

and you know what? you can make a great use of that database, if file artist/album, etc gonna be saved into a file, we culd modify any of that fields, and the info instead of xmplay modifiyng the mp3 id3 tag, could be saved to the database file. (no need to implement id3 edition)
so i guess the list should read id3 tags (if present) for first time addition, then just load a fast database as you said.

And what if the database is lost/corrupted? Support for ID3/OGG editing is still required, in order to update the tags in the files (otherwise you get inconsistencies).

[fernsx]

Please clarify what you mean by "with additional colomns etc".

Maybe "type", "number of songs", "estimated time of all songs in playlist", etc.

But actually, as to me, I don't need any. -))

you dont need them, why do you ask for them??

total/curent song number and total playlist time is shown as usual, check the top of the pic.

I didn't ask. Xmplay is perfect! You are asking... )))

I just made a suggetion for playlists that could help to keep xmplay minimum size.
I am against overloading xmplay for doubtable exrtra features.

c'mon !! you asked for those extra needless columns...
and i dont think this "overloads" xmplay, is something useless and maybe could be optional for people like you who wants simple boring stuff.
and remember: i am with you for keeping xmplay as fastest as it can go!!!

PEACE|||

[fernsx]

and you know what? you can make a great use of that database, if file artist/album, etc gonna be saved into a file, we culd modify any of that fields, and the info instead of xmplay modifiyng the mp3 id3 tag, could be saved to the database file. (no need to implement id3 edition)
so i guess the list should read id3 tags (if present) for first time addition, then just load a fast database as you said.

And what if the database is lost/corrupted? Support for ID3/OGG editing is still required, in order to update the tags in the files (otherwise you get inconsistencies).

maybe backing up your database file would solve that.
and ID3 edition  "IS ALLREADY IMPLEMENTED", i use the winamp in_mp3.dll for that, and works great.
we all know xmplay reads tags perfectly, so if you modify any file id3 tag, a right click in the updated file, and a menu option for updating tag info would work. or select the updated file, and press F5 for refreshing its info from Id3 tag is also a nice thing.

[Torkell]

and ID3 edition  "IS ALLREADY IMPLEMENTED", i use the winamp in_mp3.dll for that, and works great.
we all know xmplay reads tags perfectly

There have been a few bug reports regarding differences between the handling of tags in XMPlay and the in_mp3/in_ogg dlls. Native tag editing would remove the need for in_mp3 and in_ogg (which are only used for tag editing), ensure that what you set as a tag is what XMPlay reads as a tag, and possibly remove confusion in tag editing (e.g. a dedicated "edit file details" menu item, as opposed to "plugin file info").

, so if you modify any file id3 tag, a right click in the updated file, and a menu option for updating tag info would work. or select the updated file, and press F5 for refreshing its info from Id3 tag is also a nice thing.

The way I see it is that any changes to the file details (by this I mean title/album/artist/tracknum), should update the file. The local database is only a cache because reading the details from every file is very inefficient, and requires all files to be accessible at the time. Having a 'local database' speeds up reading the file info, but the files themselves should be kept up to date with changes and be used should there be a difference between the cached data and the actual data. When you get down to it, most of the data contained in a .pls file is just cached (title, length) and overwritten by the actual file detials if there's a difference.

[Ian @ un4seen]

Nothing's definite at this time, but I am considering adding tag editing and/or native input plugin support for 3.2 ... of course, if they do happen, that makes this idea more feasible.