Oldplay V0.97


Manwe
I'm listening to it now, not sure what i should be looking for though.
Also i'm not expert on tracked formats, so if you could explain how it sounds like when you skip a pattern it'll be helpfull.
What's usually the problem is that some samples are trashed, if you are missing a certain sound you can help me out alot by telling me how it was coded (such as 16-bit signed PCM data which you got for almost all samples in this song)

Evil Dragon. Interesting problem. Making oldplay recognize prefixes.. erh, wont be so pretty to code. I'm no expert on the uade plugin i'm afraid, but i'll take a look at it
I fixed so it'll find prefixes as well. i just played a mod.somethingsomething
Although i got some trivial errorrs in mdat. Problem is that FAT is a piece of crap
it's supposed to be named ./players/ENV/
but that's impossible and it ends up beeing ./players/env
I'll see what i can do about it
 
Micket posted on Jan 5 2007 said:
Evil Dragon. Interesting problem. Making oldplay recognize prefixes.. erh, wont be so pretty to code. I'm no expert on the uade plugin i'm afraid, but i'll take a look at it
I fixed so it'll find prefixes as well. i just played a mod.somethingsomething
Although i got some trivial errorrs in mdat. Problem is that FAT is a piece of crap
it's supposed to be named ./players/ENV/
but that's impossible and it ends up beeing ./players/env
I'll see what i can do about it
Click to expand...

Well, you don't NEED Prefixes. If you can fix it that it looks for *.smpl when you load a *.mdat or *.tfmx (or any of the tfmx formats), that will be enough. :)
 
Last edited:
Loading of samples isn't the job of the frontend. uade does that internally AFAIK.
I've already gotten prefixes to list as well, it didn't become a problem like i thought it would
But before you get your hopes up, uade seems to consider every mdat file 0 seconds long.
I can't even force it to play longer, the core just replies with a UADE_SONG_END_REPLY
I'm gonna wait on irc for the current maintainer of uade to show up and i'll ask him some questions.

With still no music to test on pokecubed i think i'll go back to improving the playlists to support relative paths to other folders, and last (if it's worth the bother) absolute paths.
 
Micket, I rendered "goodbye.it" to mp3: www.thesands.ru/goodbye.mp3
Can you run .mp3 on PC and .it on GP2X at the same time? If yes, you could easily notice the problem: GP2X will jump over parts of the song.
 
Manwe, yeah now i heared it. Thanks for the find!
There are probably lots of bugs left in libmodplug, but i wont try to fix them unless i actually have a song which i can check the results with.
So..ok, time for another release
Id say this is just alpha yet becuase i haven't tested it all out that much
Anyway, changelog time, everyone loves those!

VERSION 0.98a
Noticeable changes
* PLS and M3U playlist support. Extended and simple, as defined on
http://forums.winamp.com/showthread.php?threadid=65772
You can append (Y) or replace the playlist (B)
* Added support for GameCube music, although it sounds quite horrible right now
* Hid files you can't open from zip archives
* Prevented a couple of ways you could make OldPlay segfault
* Search for prefixes (and fileextensions) for uade
* Pressing back in playlists jumps to current playing file
* Fixed some incorrect playback on IT-songs

Interal changes
* Big changes to IFileList and all derived classes to better handle playlists
* Complete removal of IFileRef
* Addition of the class M3uPlaylist
* Addition of libpokecube and pokecubeplugin
* Various rearrangement


So now you finally got your long wanted m3u support Fishbong
The m3u files used in GME are now visible, but dont open these (you'll just flush out your current playlist since it wont be able to add anything from that file)
The m3u parser have quite specific taste, although i've tried to make it at least not segfault on incorrect playlists.


I also added support for GameCube music now.
Biggest problem; the sound is crap. Otherwise it works fine.
I'm not sure why it is so. I snagged the data in the buffer transfer in the plugin (the link between the library and oldplay) and the that stream plays perfectly when i generated a wave from it.
I also can't see anything wrong with the values submitted. They are not bigger then what other working plugins produce. I decreased the default frequency, but the same scratchy sound is played back only slower.

I'm at a loss at how oldplay handles the buffer from there on, since i barely got any experience with SDL.
Id appreciate if anyone could take a look (the interesting files are probably Fifo.cpp and MusicPlayer.cpp) and give me some pointers.

EvilDragon; Sorry, for some reason the amigaplayer isn't looking for the smpl file at all. It's not trying to open any file at all. I haven't found the reason for this yet. ( In fact if someone with strace could confirm this i'd be gladl)

And if you guys ever manage to make oldplay segfault, try to repeat it and send me the details.

(The links to the new version is the same as above)
 
Micket, you are my hero - you fixed that pattern skip bug in IT-modules !
 
Hi Micket. congrat on getting the GamCube files working with oldplay. I've had a listen and the problems sound like samplerate problems.

I was surprised that the F-Zero GX ADX files didn't play correctly though since they have a sample rate of 44100Hz

I expected problems with the ADP files (48000 Hz) and some DSP/ADX (32000Hz) there are also some files with a samplerate of 24000Hz... In any case I am back at home so I might be easier to get hold of if I can help in any way. It certainly seem OldPlay is getting GameCube samples quick enough. :)
 
I dont think the sample rate is a problem. I can play the sample at any rate i want, and the scratches are still there, just slower.

I copied the stream of shorts i get from the plugin and they play fine as well.

I'm currently working on improving the playlists. I've added saving of playlists (in my own made up format opl, since it supports files from within zips as well, just as they are in oldplay, although much inspired of the pls format)
The only problem left is adding support for another 2 colors in the config since it's a whole mess of hardcoded variables that depend on the colors that segfaults oldplay easily :(
 
Great news on the updates here. All of my homemade XM files now play flawlessly! I use this player more than GMU now. Thanks for all your hard work, Micket! How can we repay you?
 
xdreamer, why.. with a nice big "thanks" of course :)

Ok since i finally fixed GameCube music now I think it's due for another update.

For you who are currently using 0.98a the biggest update are the fact that GameCube music is now working as well as a save browser that lets you save playlists (in oldplays own format .opl that supports files from within zips)
It doesn't let you name the file however. You get a option of saving over old ones or creating a new one named playlistX.opl where X is a number 1-9 that corresponds to the first available filename (if up to playlist9.opl already exists you'll have to change directory or overwrite)
Press R to enter save mode, R again to go back to browser or select to go to playlist

Changelog: (this is continued of version 0.98a)
VERSION 0.98
Noticeable changes
* PLS and M3U playlist support. Extended and simple, as defined on
http://forums.winamp.com/showthread.php?threadid=65772
* Hid files you can't open from zip archives
* Prevented a couple of ways you could make OldPlay segfault
* Search for prefixes (and fileextensions) for uade
* Pressing back in playlists jumps to current playing file
* Fixed some incorrect playback on IT-songs
* Turns screen back on if quitting while screen is turned off
* Added support for GameCube music. Sounds great!
* Added support for oldplays own playlist format (.opl) that supports tracks within zips
* Added a save-mode for saving playlists (as .opl). Press R to enter the save browser.

Interal changes
* Big changes to IFileList and all derived classes to better handle playlists
* Complete removal of IFileRef
* Addition of the class M3uPlaylist (actually handles all playlist formats)
* Addition of libpokecube and pokecubeplugin
* Addition of SaveList and SaveState
* Various rearrangement
 
Hazey posted on Jan 3 2007 said:
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.
Click to expand...
The "extended m3u" is not a standard, and there is one area that is interpreted differently by different players: the track number field. This field specifies the internal track value to use for that track, and can be specified as either a decimal value (i.e. 12) or hexadecimal (i.e. $0C). The hexadecimal is unambiguous; it's the value to pass to the player. The decimal value is treated by some players as one-based, where the value 1 corresponds to $00, while others treat it as zero-based, where the value 1 corresponds to $01. This is a problem, and many KSS playlists I've encountered seem to require a zero-based track number. The moral of the story is to always use hexadecimal numbering in "extended" m3u playlists. Currently I think I have Game_Music_Emu treat KSS m3u playlists as using zero-based numbering, but some playlists assume one-based numbering. It's a really sorry situation because this stuff isn't documented well, and because KSS music rips could include a trivial remapping table internally so that the tracks were all together at the beginning, rather than scattered randomly from 0-255.

If you can point me to some clear documentation on KSS files and extended m3u files, I'll make Game_Music_Emu behave to the spec.

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.
Click to expand...
And some KSS files include more than one m3u to cover players that interpret the m3u differently, pretty much requiring the user to manually tell the player which m3u to use. This situation is really crappy. What we really need is a video game music information file that works with all formats, and is clearly documented so all players can handle it the same way.

Also, if a KSS file lacks an m3u, it still might contain multiple tracks, so it seems a player shouldn't unconditionally treat it as having only one track.

Even better, just recently a version of KSS files emerged where the M3U-file was embedded within the header of the KSS-file
Click to expand...
Are you referring to KSSX? So far I've never found a KSSX file, just KSSC files. When I find enough KSSX files, I'll add support to Game_Music_Emu for them. An extended m3u is much better, though, because anyone can edit it with a text editor and it works with any game music format.

"Micket" said:
I'm at the mercy at how Game Music Emu handles m3u files
Click to expand...
You can handle m3u files however you want and remap tracks before you pass them to Game_Music_Emu. Game_Music_Emu simply includes optional built-in m3u handling if you don't want to do it yourself.
 
Last edited by a moderator:
Micket, if you are still around:
I have been working on bring pokecubed up t date with the latest in_cube version. The latest edition adds a couple of formats: AFC and RSF maybe others.

I can put what I have online tomorrow, but I think I have currently broke ADX support... not entirely sure since my personal playing program to test it is very useless ;)
 
PokeParadox
Yeah i'm still here. Just a bit busy with school.
I take it you haven't based it around the changes i made to the wrapper files?
I made quite extensive changes to what i think was a better and much faster way to handle things. (Mainly changing from keeping track of time i milliseconds to using samples, also removing the "force" functions as they aren't and shouldn't be needed at all)
The stuttering you had should probably be handled by the main program and not by the wrapper (as it should only supply samples)
 
Thats good. I doubt you'll have it working with your player though
I didn't do many tests actually. Feel free to mail one that doesn't play properly (preferably small, but size isn't really an issue for my connection) to my gmail (micketeer)
 
You must log in or register to reply here.

Similar threads

EvilDragon
Oldplay v0.97 veröffentlicht
Replies
0
Views
875
EvilDragon
EvilDragon
M
Oldplay V1.20
2
Replies
23
Views
7K
Micket
M
M
Another Oldplay Update. Version 1.0
Replies
14
Views
3K
PokeParadox
PokeParadox
M
Oldplay 0.96a
Replies
11
Views
2K
Micket
M
M
Oldplay V1.31
Replies
16
Views
5K
Micket
M
Back
Top