next »

[Ian @ un4seen]

Built-in tag editting may well happen in a future release, but it can't be just built-in. It will also require some mechanism for plugins to edit tags, to support formats that XMPlay has no built-in knowledge of, like WMA. To keep the plugin system as simple as possible in it's first incarnation, I decided to save it for later (ie. not in 3.2).

Could you add ID3v1, ID3v2, APEv2 and Vorbis tag editing? The plugins should also export a flag which tell XMPlay which tag type(s) the format support, including a custom flag where all tag handling is done by the plugin itself.

Yep, that is what I had in mind. XMPlay would support editting of the tags it knows about (ie. ID3/OGG/APE), and the plugins would have to handle any other tag systems.

[Sebastian Andersson]

An update is available for xmp-mpc. The update includes streaming support (experimental, and only tested with HTTP streams) and an improved (faster) VBR display.

[Sebastian Andersson]

An update is available for xmp-mpc. The update uses a new version of the Musepack decoder library (libmpcdec 1.2).

[Luis Fuentes]

I hear some static at the begining of some of my encodes. Should I upload the buggy files somewhere?

[Sebastian_Mares]

I hear some static at the begining of some of my encodes. Should I upload the buggy files somewhere?

 

[Tsorovan]

Well, I did some more testing and yes, it is this plugin that occasionally (very often) still adds unplayable files like .png, .sfv and .txt. It's driving me completely bananas, to the point that I'm right now using the otherwise inferior in_mpc.dll.
A fix?

Thanks!

[Tsorovan]

More info:

What might make this difficult to track down is that I had 100% reproducibility with this plugin on Dec 8. Today it doesn't happen. My files and settings have not changed.

Arfgggggg.

[Edit] Though, an .m3u slips through the cracks for one certain dir. There is, to my eyes, nothing specific about the composition of this dir compared to others that could cause this to happen. It contains files like this:

01-xxxxxx_xxxxxxxxx-xxx.mp3
[...]
00-xxxxxx_xxxx-xxxxxxxxx-2004-xxx.sfv
00-xxxxxx_xxxx-xxxxxxxxx-2004-xxx.m3u
00-xxxxxx_xxxx-xxxxxxxxx-2004-xxx.nfo

The x:es say the same thing, so to speak.

Renaming xmp_mpc.dll to xmp_mpc.dllx and restarting XMPlay makes XMPlay not add the .m3u. It's really quite serious because the .m3u gets put at the beginning of the playlist, is redlined and XMPlay fails to keep on traversing the playlist.

And as said, some days it can keep on doing this for more than just one specific dir. I'm sorry I can't provide clear info for 100% reproducibility... this is not the first plugin behaving like this though, and others have been fixed.

I found another dir also behaving like this, but xmp_mpc.dll adds 3 PNGs instead. File types in this dir:
.flac
.cue (I renamed them to .cuex without any difference)
.md5
.jpg
.m3u (2)
.pdf
.png (3)
.txt
.log

.m3us do NOT get added, only the .pngs.

Here's another thing: When dragging the files (all the files in the dir) selected to the playlist, it works as it should. When dragging the dir containing the files to the playlist, same.

Dragging the files or dir containing them to the main/mini panel to open them (and replace the playlist), something which I do 95% of the time since I don't use very big playlists, this causes all these bad files being added.

[branko]

I can't see any info about replaygain. Does this plug-in shows replaygain info and does it use replaygain at all?

[Tsorovan]

Well, I did some more testing and yes, it is this plugin that occasionally (very often) still adds unplayable files like .png, .sfv and .txt. It's driving me completely bananas, to the point that I'm right now using the otherwise inferior in_mpc.dll.
A fix?

Thanks!

More info:

Here's another thing: When dragging the files (all the files in the dir) selected to the playlist, it works as it should. When dragging the dir containing the files to the playlist, same.

Dragging the files or dir containing them to the main/mini panel to open them (and replace the playlist), something which I do 95% of the time since I don't use very big playlists, this causes all these bad files being added.

Please? I really want to use the native MPC plugin but I can't since this is a showstopper bug. If not, could Ian please add an undocumented "never ever add these file types" INI setting (if you think it's outrageous to have such a setting in the GUI)? I've noticed the WMA plugin wants to add (and does play the audio part of) video WMV files too and I don't ever want to play those in XMPlay.

[Sebastian Andersson]

Well, I did some more testing and yes, it is this plugin that occasionally (very often) still adds unplayable files like .png, .sfv and .txt. It's driving me completely bananas, to the point that I'm right now using the otherwise inferior in_mpc.dll.
A fix?

Thanks!

More info:

Here's another thing: When dragging the files (all the files in the dir) selected to the playlist, it works as it should. When dragging the dir containing the files to the playlist, same.

Dragging the files or dir containing them to the main/mini panel to open them (and replace the playlist), something which I do 95% of the time since I don't use very big playlists, this causes all these bad files being added.

Please? I really want to use the native MPC plugin but I can't since this is a showstopper bug. If not, could Ian please add an undocumented "never ever add these file types" INI setting (if you think it's outrageous to have such a setting in the GUI)? I've noticed the WMA plugin wants to add (and does play the audio part of) video WMV files too and I don't ever want to play those in XMPlay.

I'm sorry for the late reply, but I've been slightly busy with other things. I'll look into this ASAP.

[Tsorovan]

Great! Thanks!

[Sebastian Andersson]

I'm sorry for replying this late once again, I've lacked time and resources to offer any support. Here's an update to try...

     http://www.un4seen.com/filez/2/xmp-mpc.dll

[VZZ hZZ]

gracias amigo!

[Tsorovan]

Seems to work. Thanks! I tracked down some more PNG loadage though, and that seems to be the AAC plugin's fault. At least they get added last, and won't prevent XMPlay from advancing the playlist; still a nuisance however.

[Sebastian_Mares]

I see this more as an XMPlay issue. If plugins tell XMPlay what extensions they support, XMPlay should only pass files with that extensions to the plugins and not dump the whole crap (all kinds of files inside a directory) to the DLLs and let them handle filtering.

[Tsorovan]

I fully agree. You plugin coders shouldn't have to deal with this. Ian?

[Fraggie]

Verifing file content by extension is bad.

[Sebastian_Mares]

It's the reason why they are there in first place. If people were dumb to rename their MP3s to "*.Blah" it's they're fault.

[Alexsource]

Agreed, but some amiga files tend to have extention first, then filename. Like in: med.happytune
Maybe we could get somewhere in between... I don't know. Anyway, it's for Ian to decide.

[Tsorovan]

I don't see a problem with those files. They should be renamed. They're not following the nomenclature, and are thus invalid (as prefix/suffix form) in Windows, the OS XMPlay runs on. Windows can't properly handle those, and thus some half-assed support should not be hacked into XMPlay, just because some ancient OS did it that way.

A banlist would work fine for me though, although it's not an elegant or a maintenance-free solution.