aargirakis / BZRPlayer

Audio player for Windows that plays over 650 different fileformats
http://bzrplayer.blazer.nu/
GNU General Public License v3.0
10 stars 0 forks source link

incorrect naming for playlist tracks (mods) #358

Open ciros88 opened 1 year ago

ciros88 commented 1 year ago

thanks to #100 , now when you add a file like a mod (xm.. or another exoctic file format) on a tracklist, its filename is displayed first. then, when you play it, the 'internal' track title is displayed instead. this behaviour is suboptimal (see #361) but makes sense.

moreover, thanks to #73 this behaviour was fixed also for playlists for what i remember.

but, if you add a playlist that have mods, seems that the title is taken from the #EXTINF m3u field not from the filename. i think it should taken from the filename, i mean the filename should be displayed until you play the track and then the 'internal' file title should be displayed (taken from the file not from the playlist #EXTINF) as happens with sparse mod files.

aargirakis commented 1 year ago

I disagree. The only reason we don't display the "real" name/audiolength etc. is because we don't know it until we load the file. But, it the playlist already supply that information we use that "for free". Otherwise our playlists would never display track names/song lengths etc. every time we start the program.

ciros88 commented 1 year ago

Yeah but this led to inconsistent behaviours. One for all: if i edit a mod or an mp3 id3 the playlist will continues to display the old infos in the hardcoded extinf

aargirakis commented 1 year ago

That's the only time if will be inconsistent though. Then when you play the file the data would be updated again. And how often do you edit a mod or mp3?

ciros88 commented 10 months ago

And how often do you edit a mod or mp3?

it happens... and if u are a musician then it happens more often.

the key point, in my opinion, is that the #EXTINF m3u field is a placeholder added in days (the nineties) when that information was useful, but nowadays using this field brings more drawback/inconsistencies than real benefits. m3u should be threated like a file indexing/grouping, where the only real useful information is a filename with its path (and subtune eventually), the rest should be player duty IMHO. also vlc, qmmp, winamp, (i have only these for trying right now) skips the #EXTINF and use the real one (vlc and qmmp do it as soon as the playlist is added, winamp do it when the track is played). i think it the better design strategy for handling this scenario

think about the other m3u fields like:

EXTALB:

EXTART:

EXTGENRE:

etc,...

why bzr2 doesn't supports them also? because we already know it is better to get them from the file directly, and with #EXTINF should be the same