next »

[Ian @ un4seen]

I've actually been experiencing the same thing too, but it rarely fails when dragon dropping (from XMPlay) to explorer.

I think I've found a problem in that stuff (dragging from XMPlay), so here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still have the trouble, and I'll send a debug version to get further info on it.

[Jace]

Have tried twice now, success rate: 100%! So for now, I dare claim it fixed (on my part at least.)
Just out of curiousity, what kinda problem was it?

[Ian @ un4seen]

The list of dragged files is meant to be terminated with a double null, but on Unicode systems XMPlay was including only one-and-a-half

(three 0s instead of four)

[Y@nek®]

I think that a good idea is integration of (an option) vis plugin/ album picture inside of Xmplay skin.

On example:



With option to change and remember of size picture.

What do you think?

[Dotpitch]

I think that a good idea is integration of (an option) vis plugin/ album picture inside of Xmplay skin.

Barna made xmp-coverart over a year ago, try that.

[Pike84]

Not exactly the same thing.

I think it's kind of a neat idea, but not nearly important enough for me to support, if it takes time away from other development.

[Y@nek®]

I think that a good idea is integration of (an option) vis plugin/ album picture inside of Xmplay skin.

Barna made xmp-coverart over a year ago, try that.

I mean in main window.

[Ian @ un4seen]

I think it may be possible to include a vis area in the main panel. I'll look into it. Of course, it will delay 3.5 for another 6 months though

[Dotpitch]

I think it may be possible to include a vis area in the main panel. I'll look into it.

Sounds good to me .

Of course, it will delay 3.5 for another 6 months though

.

[Y@nek®]

I think it may be possible to include a vis area in the main panel. I'll look into it. Of course, it will delay 3.5 for another 6 months though

Thank you

[piovrauz]

well, if it's only a 6 months delay...

[heftig]

I think it may be possible to include a vis area in the main panel. I'll look into it. Of course, it will delay 3.5 for another 6 months though

I thought you didn't want to release without proper i18n+l10n, anyway.

[piovrauz]

as long as release dates match pink noise spectrum it's ok.

[amit]

Recently I have stumbled into a small issue when archiving cds as CUE sheets with separate track files: In order to maintain all the data of original CD Sometimes gaps are added as separate files. These files are stored as regular audio files but with '(HTOA)' added to their names.

I know there is a way to avoid the addition of pre-configured filetypes to the playlist. Is there a way to extend this capability into checking also the file names? Then file names containing a pre-configured text mask, in my case - '(HTOA)', will be ignored and won't be loaded to the list.

Thanks.

[Ian @ un4seen]

I figured 3.5 needs at least one more popular new feature to keep the pitchfork-wielding mob at bay. Crossfading seems to have been the most requested feature over the years, so here's an update with that...

   www.un4seen.com/stuff/xmplay.exe

A few things to note: Crossfading is only applicable between tracks with the same sample format (the "Apply sample rate to all file formats" option can be enabled to make it pretty much always so). Crossfading currently applies to sub-songs too, but not CUE sheets. The crossfade length is a maximum, eg. it could be shorter if the track is short. DSP setting changes are not delayed by the crossfade option, but decoder settings (eg. the MOD options) are.

Another popular request that I looked into is splitting CUE sheets into separate tracks, but there are issues, including a pretty big one: splitting a file into separate tracks will introduce a disruption between the tracks with file formats that don't naturally have precise seeking (eg. MP3), as it involves seeking to the CUE positions. I think seamless playback would be an important requirement of CUE tracks, so I'm not sure if that'll make it to release. I'm also still looking into the plugin playlist manipulation stuff that I mentioned previously, but there are issues to overcome with that too, and I'm not sure it's worth delaying 3.5 any further with that.

Anyway, please report any problems with the crossfading (or anything else).

[saga]

Ok, this sounds cool of course, but this version has several issues:
- ID3 tags are shown in the info windows here, but when playing the tune, the playlist entry changes from "artist - tune" to filename display
- Also got a crash when opening an MP3 file, but couldn't reproduce it.

to keep the pitchfork-wielding mob at bay.

I gotta remember that one But I at least would not have needed crossfading, personally.

[r]

I know it's probably been brought up on numerous occasions, but what about basic ID3 tagging support as a feature?
I keep reverting to Winamp for this all the time...

Will test out the cross-fading.
CUE sheet splitting sounds cool, but like you said Ian, there's a myriad of issues that can be raised.

I think if you do enable cue sheet splitting, that you do not erase the original longform audio file (at least as a default option).  And maybe, make cue sheet splitting, audio format dependent in the "Options and Stuff" config area. (eg. select the audio formats for cue sheet splitting)... I dunno, just throwing suggestions out there.

[saga]

I keep reverting to Winamp for this all the time...

you can put winamp's in_mp3.dll in xmplay's directory to use winamp's id3 tagger. same goes for in_vorbis.dll.

[Brian]

I know it's probably been brought up on numerous occasions, but what about basic ID3 tagging support as a feature?
I keep reverting to Winamp for this all the time...

There's a workaround for this. Put the Winamp in_mp3.dll into your XMPlay plugins folder, and you can then edit the tag of a file in the library or playlist by right-clicking on the entry and selecting `Plugin file info'. Of course this only provides tag editing for filetypes supported by the plugin. And as has often been mentioned, the Winamp plugin doesn't override XMPlay's native mp3 decoder when it comes to playing the file. I'm attaching an older version of in_mp3.dll which works on my system.

[amit]

I know it's probably been brought up on numerous occasions, but what about basic ID3 tagging support as a feature?

Some time ago there was a proposal to allow opening tracks with external applications. This way you could open the tracks with your favorite  tagger (mp3tag etc'). I am not sure though what happened with this.

Another popular request that I looked into is splitting CUE sheets into separate tracks, but there are issues, including a pretty big one: splitting a file into separate tracks will introduce a disruption between the tracks with file formats that don't naturally have precise seeking (eg. MP3), as it involves seeking to the CUE positions. I think seamless playback would be an important requirement of CUE tracks, so I'm not sure if that'll make it to release. I'm also still looking into the plugin playlist manipulation stuff that I mentioned previously, but there are issues to overcome with that too, and I'm not sure it's worth delaying 3.5 any further with that.

I am not very keen on the splitting subtracks into virtual tracks idea, but It would be nice to have some control on which subtracks get played. Here is another suggestion: Can you add for files with cue sheet reference a multiselection submenu of their subtracks? By defualt all subtracks will be ticked (enabled) and unticking (Disabling) will cause them to be skipped. This way the subtacks will retain their original order and will not pose any problem for continuous gapless playback. Only skipped tracks will have to be handled...