Oldplay V0.97


Micket

Member
Joined
Jul 16, 2006
Messages
196
Age
40
Location
Sweden, Gothenburg
Website
www.micket.com
EDIT AGAIN: Now it's 0.98
Changelog on page 2, same link

EDIT: Acutally i updated it again, right now i'm calling it 0.98a
Although who gives a shit about version names, the interesting stuff is the changelog anyway. Look further down.
The links are the same, i just replaced the files

Well i made another update to OldPlay
http://www.micket.com/oldplay.zip [2 MB]
http://www.micket.com/oldplaysrc.zip [22 MB]

screenshot.png

This is what it looks like now, of course it's still possible to use the old default.cfg
(the colors look very different on the gp2x)

Big news are probably that uade is back in business, well at least as much as it was last time.. and. well i'll just paste the changelog

* uade supported again (as far as v0.95 did)
* Enabled underclocking by default
* Fixed XM, FAR, MDL in libmodplug
* Updated GME to v0.5.2 and used more of it's features:
* Added support to vgz, hes, kss, ay, sap
* Support for m3u files for all game music
* Fake stereo for mono sound in game music
* Seeking in all single tune game music files
* Better effort at song lengths in game music (no more neverending tunes)
* Automatic silence detection (ends tune)
[cut]
* Better handling of multitune songs in playlist
* Scrolling text
* Subtune name field
* New colors in default.cfg
* #FF00FF transparent in logo.bmp
* Better handling at unplayable tunes
* Added textual man page (supported in gmenu2x > v0.8)

Internal changes
* Changed lots of small bits and pieces
* Reworked a bit of the structure in PlayerApp, Playlist and MusicPlayer
* Made a library out of libzip (updated to latest version)

I'm not sure what i'll do next.
Possibilities are; gsf, sndh, ogg, flac, mikmod's supported formats (that modplug can't handle well or at all)
Dunno about wma, could cause license issues? Reading licenses is boring

If you come across xm, mod, mdl, med, okt, ult, it, far, ptm, s3m songs that doesn't work, or have messed up samples send them to me and i'll have a look at libmodplug
(If possible, test with something using libmodplug on your computer and make sure libmodplug actually can handle them properly)[/cut]
 
this looks very sweet, if you add vorbis and mp3(if you dont already have it)i'd use as default player.

about wma, well.. its not licenses you need to worry about, its patents, however, as long as you release as you do now, that shouldnt be a problem.. ffmpeg project has a wma decoder, licensed under the LGPL.
 
Redeeman: mp3 is support and ogg is definitly on the TODO-list

Nothing beats good old game music.
If you think there are something wrong in the genereal behaviour when playing or anything like that tell me and i'll take a look at it.
I've tried my best to make it behave like i want it too, but that might not be the appreciated by everyone else.

Also, Fishbong, the playlist are just for the game music formats (in fact requiered by KSS files as they dont have embedded information on subtunes)
They are requiered to only contain a single file/song, and will be searched for automaticly when you start a game music format (the same name with m3u file extension, that is, AGoodSong.kss should also contain AGoodSong.m3u in the same folder)
They are supported for all formats, but you'll probably only find it for KSS and maybe HES files (the KSS playlists are usually crappy written and might not work)

I might look into using m3u playlists to load into the general playlist for the next release though, it shouldn't be that hard at all to implement.

Also, be sure to tell me it the over(amiga) and underclocking causes any trouble, or if it's not enough power to play certain tunes.
I'll look into adding configureable clockrate for different formats into the config file as well.
 
Oh, OK, so no real Playlist support :( that´s what i´m looking forward for the most... Oh well, i´m sure you´ll add it someday. Knowing that the project isn´t abandoned is the main thing.
 
...
Also, Fishbong, the playlist are just for the game music formats (in fact requiered by KSS files as they dont have embedded information on subtunes)
They are requiered to only contain a single file/song, and will be searched for automaticly when you start a game music format (the same name with m3u file extension, that is, AGoodSong.kss should also contain AGoodSong.m3u in the same folder)
They are supported for all formats, but you'll probably only find it for KSS and maybe HES files (the KSS playlists are usually crappy written and might not work)
...

Well, I'll be sure to pass on that comment to those that rip KSS files. :p Though I have to say in all honesty most developers of plugins or players for other platforms seem to handle it fine. The only sloppily written M3U-files I've come across, when it came to KSS, included directory information where there was none necessary.

Anyway, I wanted to point out that KSS files do not by default require the presence of an M3U-file. A large portion of the KSS files out there, which are original music, contain only one tune anyway. This basically follows the default behavior of KSS replayers (and other formats) where the first subtune is played and all subsequently following subtunes are played in the order they appear in the KSS-file. And, as you've surely noticed while implementing M3U-support :), M3U-files change this behavior and only play the subtunes as they're indicated in the playlist.

Now I don't have a GP2X so I can't tell how you've implemented anything relating to KSS, but I wanted to let you know of some of the different KSS-files that are also out there. For instance the assumption that the M3U-file is always similarly named as the KSS-file is regrettably wrong in many a case. This because the corresponding KSS-file is pointed at within the (hopefully correct) M3U anyway. Even better, just recently a version of KSS files emerged where the M3U-file was embedded within the header of the KSS-file, thus negating the need to have the original files have the same name to begin with. Though I reckon you won't come across many of this kind yet.

I take it you've also come across the difference between regular M3U- and extended M3U-files?

If you want some examples of all of the mentioned combinations I'd be happy to provide you with some, though I can tell from the provided screenshot you've at least got a few single-tune and multi-tune ones in your collection. ;). Or you can find some at my site http://home.hccnet.nl/c.v.walta/ or by following the links there.

I hope this information has been useful to you! Thanks for supporting the KSS-format on yet another platform!
 
Last edited by a moderator:
Micket, in the beta testing, mp3 and ogg worked fine, why did you decide to can them in this release?
 
yes lossless audio codec support would be great, Oldplay will be the first GP2x player that can support it ;)
Flac, Ape (Monkey’s Audio)...
 
Well, I'll be sure to pass on that comment to those that rip KSS files. :p Though I have to say in all honesty most developers of plugins or players for other platforms seem to handle it fine. The only sloppily written M3U-files I've come across, when it came to KSS, included directory information where there was none necessary.

Anyway, I wanted to point out that KSS files do not by default require the presence of an M3U-file. A large portion of the KSS files out there, which are original music, contain only one tune anyway. This basically follows the default behavior of KSS replayers (and other formats) where the first subtune is played and all subsequently following subtunes are played in the order they appear in the KSS-file. And, as you've surely noticed while implementing M3U-support :), M3U-files change this behavior and only play the subtunes as they're indicated in the playlist.

Now I don't have a GP2X so I can't tell how you've implemented anything relating to KSS, but I wanted to let you know of some of the different KSS-files that are also out there. For instance the assumption that the M3U-file is always similarly named as the KSS-file is regrettably wrong in many a case. This because the corresponding KSS-file is pointed at within the (hopefully correct) M3U anyway. Even better, just recently a version of KSS files emerged where the M3U-file was embedded within the header of the KSS-file, thus negating the need to have the original files have the same name to begin with. Though I reckon you won't come across many of this kind yet.

I take it you've also come across the difference between regular M3U- and extended M3U-files?

If you want some examples of all of the mentioned combinations I'd be happy to provide you with some, though I can tell from the provided screenshot you've at least got a few single-tune and multi-tune ones in your collection. ;). Or you can find some at my site http://home.hccnet.nl/c.v.walta/ or by following the links there.

I hope this information has been useful to you! Thanks for supporting the KSS-format on yet another platform!

I'm at the mercy at how Game Music Emu handles m3u files (although i can suggest changes to Shay how to handle them)
I've managed to play one tune that was without m3u file, but several others didnt work. You also dont get any subtune name or tracklength of course (but there is silence detection and a default length)

And for filenames.. this is getting somewhat bothersome. I plan to support m3u files as normal playlists, so loading them should create normal playlists (which would conflict with creating subtune playlists as it's handled entirely different in oldplay)
In short, i have a hard time getting perfect behaviour from everything.

PSyMastR
But mp3 is supported. I haven't done anything to it! And ogg.. it's never been supported..

Yod4z, it'll be pretty touch to implement though (with memory limitations etc.) so don't expect it for the next release, but i'll take a look
 
Last edited by a moderator:
Great news about the update. May I suggest you try and add Game Cube stream support to the player.

I tried to make a standalone player here: http://www.gp32x.de/board/index.php?showtopic=32634

It's based on the in_cube winamp plugin

It should be possible to get fullspeed playback, although I couldn't get it there. But I don't think I quite have enough experience. :)

psf should be possible fullspeed and also a format that would be nice.
usf would be nice... but I think that might be accross the possibility threshold.
 
Last edited by a moderator:
Sounds interesting. Although there are alot of things to implement for just me. If you want i can explain in detail how the plugins are built for OldPlay and you could possible convert your player to confine to that
What the plugins want is that the library in question can fill a buffer with a certain amount of samples (for a given frequency)

With libraries such as Game Music Emu it's as simple as;
Code:
static int fill_buffer(signed short *dest, int len)
{
	gme_play(emu, len/2, dest);
	return len;
}

If you think you can whip something up in your player that can fill a buffer (i.e. not handle any timing or anything, just fill with samples as fast as possible) then i can easily put it in

I'm working on m3u support atm. It turned out to be a bit bothersome. given that the song have to be in the same folder then i might be able to whip something up quick, but subfolders or completely different locations can turn out to be bothersome
 
Indeed. Im looking through the main method. Most of that stuff you wont have to worry about when writing a plugin for oldplay.
This should be hard at all, the setup for pokecubed seems almost optimal for OldPlay. I'll give it a try, first i need to isolate all needed files and make a small library out of it.
If you have some songs lying around pass them onto me (gmail; micketeer)
 
There aren't that great libraries for them. I was taking a look at gfs, but i got stuck when i couldn't compile the VBA part for the gp2x. Might give it some more try by combining it with the gp2x version of VBA
PSF i haven't looked into.
Writing plugins aren't that hard actually. Whats important is that oldplay gets control over the stream of samples and the possibility to ask for a certain numbers of samples to fill a buffer.
If you got that you're pretty much set.

EDIT:
I have sound from a GameCube sound file now :D
Although not much to test with
Send me any music for GameCube that you have (that's working with xmms-cube or something like that)

I also added some very..*VERY* basic playlist support.
In fact, it's so basic it just reads the lines from the file and lists those files and add them (if they are found and can be played)
The files also have to be in the very same folder, basicly a "ls -1 > playlist.m3u" works fine

*Note i haven't updated the zip yet, i need to polish things up before i can even call it a beta release as GameCube music currently crashes after a second
 
Very good news :)

Well, I'm still trying to get all my Amiga Musics working.
Most did work by changing the extension to the one in the eagleplayer.conf :)

However, no luck with TFMX.

You might know that TFMX files consists of two files. The music and the samples.
On the Amiga, the name was mdat.song and smpl.song
According to the UADE FAQ, UADE also expects them that way.

OldPlay however expects extensions instead of prefixes.

If I rename the song to mdat.song, it can't be found. Only if it's named song.mdat.

But regardless how I name the samplefile, the file remains unplayable.

I guess it's because Oldplay can't find the samplefile - but what name does it expect?
I couldn't find any logfiles with error messages...

Any ideas?
 
I tested Oldplay with my old IT-tune, it skips some patterns while playing (ModPlug on PC doesn't). Here is the tune: www.thesands.ru/goodbye.zip (1.2 Mb)
 
Back
Top