Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Codecs
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by gama - 2011-01-26
Last edited by Buschel - 2011-07-04

FS#11906 - New GBS (Game Boy Sound) codec based on glargg's Game_Music_Emu-0.5.2.

Just finished a new gbs (Game Boy Sound) codec based on Game_Music_Emu 0.5.2. http://www.slack.net/~ant/.

Features:

  
  - Metadata parsing
  - Track selection (it works like the nsf codec)
  - 44Khz Interleaved stereo sound.
  - Fading works (Maybe i have to reduce this value)
  - It uses the fast version of blargg's blip_buffer, so the sound quality
    is quite nice.

* There is no GBR support *

Tested it on a Sansa Fuze V2 and it’s working very nice. The diff was made from Svn revision 29139. I haven´t tested it on release version 3.7.1.

By the way, i had never used svn before (except for chechouts ;)) so i hope the patch works fine. If the codec works fine maybe i can work on other formats supported by Game_Music_Emu-0.5.2.

Cheers.

Closed by  Buschel
2011-07-04 05:53
Reason for closing:  Duplicate
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Replaced by FS#12176.

You seem to have forgotten to attach the patch.

gama commented on 2011-01-26 20:06

Oh, sorry.

The Game_Music_Emu library seems to support a lot more formats. Is there a reason you only ported gameboy sounds over?

gama commented on 2011-01-27 21:31

Because it would have taken a lot of time. Now that i have ported the core library (blip_buffer, multi_buffer and rom_data) it will be easier to port other supported formats.

is it possible to port the vgm(vgz) format support? it will be great if rockbox can playback megadrive’s music!

gama commented on 2011-01-28 15:09

The vgm tunes usually are too cpu demanding, due to the use of several sound chips at the same time, i remember even
PSP i had to overclock to get some fluid playback. It may work without the fm chips but i think most songs relies at least
ym2612 chip to play fine.

I guess i will leave it for later but i can’t promise anything, currently i’m working on the HES format.

well~ the hes is another awesome game music format!

I’ll need to test further, but I’ve noticed that when a GBS precedes another multi-track format, the final track of the GBS is instead the counterpart from the next multi-track. e.g. I keep all my SIDs, NSFs, etc. in a single folder. With Bomb Jack.gbs and Bubble Bobble.sid in the same folder, 0:05/0:05 in Bomb Jack plays 0:05/0:11 in Bubble Bobble.sid. Also, the next time Rockbox tries to update metadata, it gets only garbage, presumably from reading GBS offsets in a SID file. Same behaviour with Pop Up.gbs 0:02 leading into Shadowgate.nsfe’s 0:02.

gama commented on 2011-02-07 03:57

Yes, i noticed that too and i’m trying to fix it. By the way i have updated the plugin to version 0.2, fixed and changed some things and added some features, will upload it as soon
fix that bug. And also i have finished the HES (Turbografx, pcengine) codec, it works the same way than the gbs codec.

I’m also working on an atari sc68 codec ;).

gama commented on 2011-02-10 14:37

Hi, i have updated the gbs codec, it seems the bug mentioned above is fixed.

Changelog:

  1. Fixed a bug when reaching (or seeking to) the last subtune in a track that caused some

strange behavior, and prevented changing to next song automatically.

    Note: it seems the nsf codec suffers from a similar bug (?).
  - Fixed a bug in rom_data.c that may have caused a bus error.
  - Reduced sound gain to 0.75 %.
  - Blip_Buffer bass frequency is set correctly now.
  - Added m3u playlist support, those should be placed in the same folder as the
    song.
  - Added strrchr and strcasecmp to codec structure and codeclib since they are
    needed by the m3u_playlist code.  If this is a no go, they can be 
    implemented statically inside the codec.

Well i think that’s all. I have finished the HES codec but i still need to make a proper patch.

m3u playlist support? Rockbox already supports them, and you can even mix formats.

In fact, when you play an entire folder it kind of creates a playlist internally.

GBS files have a specific, nonstandard M3U format which goes along with them and provides metadata like track titles, songlengths, etc. for each subtrack. It’s quite likely Rockbox’s current M3U support wouldn’t handle those specifically associated with GBSs.

I doubt it. Can the metadata can only come from those playlist file (i.e. not be embedded)? If it’s really needed it should be part of the metadata parser and for real playlist the built-in ones should be used.

Indeed, GBS has no support for rich internal metadata. If I recall correctly, there are fixed width fields for artist and game, and that’s all. Here’s a sample from a GBS-M3U:

Pop Up (1991)(Bit Managers)(Infogrames).gbs::GBS,0,Main
Up (1991)(Bit Managers)(Infogrames).gbs::GBS,1,Game Over,0:00:06,,0:00:00,

The values after the filename refer to subtrack #, subtrack title, track length (GBS files have the capacity to play indefinitely), and fade-out time. Standard practice is to let the track loop once then fade out at the end of the second playthrough–so the actual track length for “Main Theme” there is something like 2:37, and the final length after reading the M3U is 5:20 (5:15 + 5s fade). The game over sting, on the other hand, does not loop, hence the six-second runtime and 0s fade.

The M3U does also perform its function as a playlist–tracks may be reordered or omitted at will, e.g. to match the in-gameplay rather than in-ROM order (the former) or to simply skip sound effects, which most aren’t particularly interested in hearing (the latter). So both of its functions are important and likely not catered to by Rockbox’s standard M3U parsing, which–correct me if I’m wrong–is on a file-by-file basis and does not deal with subtracks, hence the “skip to time” system in use by all multitrack formats under Rockbox.

http://pastebin.com/raw.php?i=f5tBEKs7 Having an error while compiling. used
there was also errors while patching so i edidted metadata.h and metadata.c manualy

try this patched file

It compiles fine but playback fails showing “Undefined instruction at 21E7F508”

eh...forget it, i’ll try to fix it once more...

gama commented on 2011-02-14 14:08

Oh, i used 29139, but rockbox is a very active project. Should i make the HES patch based on the latest revision?

yup better to do that

gama commented on 2011-02-14 16:02

And about the file open, read, etc, it seems they are only defined in devices that support
it would be easier to define them for all targets?.

dunno

i modified the codecs.c/h to make it compiled and played in no-recording-support device, but seems that it couldn’t play hes-m3u
files attached, for gbs as well as hes

fix: remove redefinition

gama commented on 2011-02-17 03:11

I’m also looking at it, by the way i made some mistakes when i added strchr and strcasecmp to the codecs api structure. They should be placed at the end for now. Here is a fixed patch made from revision 29307. But I haven’t solved the m3u playlist yet.

i modified the codecs.c/h to make it compiled and played in no-recording-support device, but seems that it couldn’t play hes-m3u
files attached, for gbs as well as hes

I will test it on the simulator with a no-recording target. Please let me know if you find how to solve the problem.

gama commented on 2011-02-17 03:13

I forgot to post the patch :)

i’ve made a mistake, the m3u was auto loaded when i play the gbs/hes files...it’s
strchr and strcasecmp can be placed in the struct wherever you want, the old location also worked.

gama commented on 2011-02-17 15:27
the strchr and strcasecmp can be placed in the struct wherever you want, the old location also worked.

Yep but it was killing backwards compatibility i think. And according to the codecs.h file, codecs api version should be updated when the codecs structure changes, but I guess i have to leave that to a rockbox dev.

This patch builds and works on my iPod video, but fails to build for iPod mini 2G with the following error:

/Users/rmenes/rockbox/apps/codecs/libgbs/m3u_playlist.c: In function
error: ‘struct codec_api’ has no member named
error: ‘struct codec_api’ has no member named
error: ‘struct codec_api’ has no member named
*** [/Users/rmenes/rockbox/ipodmini2g-build/apps/codecs/libgbs/m3u_playlist.o] Error 1

Also of note, most GBS files tested sound very accurate and play in realtime. Some GB games that do special tricks with the hardware to simulate drums using white noise (e.g. Pokémon Red/Blue) seems to have some minor timing issues where the “drum” sound plays out of sync with the other channels.

Robert Menes (RMenes379)

Did you tried JoshuaChang’s fix? Problem is that opening and reading files (m3u playlists here) supported only by devices that supports recording

I would recommend using the latest version of Game_Music_Emu, 0.6-pre, which is available here: http://kode54.foobar2000.org/Game_Music_Emu-0.6-pre.tbz It contains several important improvements, and also changes to the GBS support that fix numerous bugs, some of which may cause it to crash. Blargg still hasn't seen fit to push it as a release on his site yet, for some reason, but I have permission to share this version.

And yes, that version does fix the timing issues with Pokémon Red/Blue.

gama commented on 2011-02-28 15:19

Yeah i'm trying to port the gbs emu from version 6, but i will need more time, since i need to port the apu, cpu and emu stuff again, but it isn't too much work really, so if you don't mind to wait a couple of weeks i will work on it. Right now i'm testing a new nsf codec based on gme version 6, i know there was already a nsf codec but this one has support for every apu, and i'm pretty sure it is better than the current nsf emulation and sound quality. Even vrc7 songs are working on the sansa fuze v2.

>vrc7 songs Holly smoke finally we will be able to fully enjoy homebrew NES music :*)

The current NSF codec was ported from NotsoFatso, where NSFe originated (I'm pretty sure). Since you're using GME, if you do port over the NSF from GME, you would still support NSFe, right (my recollection is that GME has NSFe support, as well as the M3U support)? As for the M3U playlist loading, that's pretty cool! I, for one, would really like to see that ability added. I use NSFe files all the time, but having the ability to use the specialized M3U playlists would be great as well. Regarding VGM/VGZ support, oh PLEASE add it!!! I have a Gigabeat S60 (500 mhz CPU...), and I'd love to try it. Even if there are players that aren't fast enough to support VGM/VGZ, some of them are.... And by adding/working on it, it makes it more likely that others will work on it/optimize it for other players as well. Thank you so much for your work on GBS support! I used the old patch for a long time, until it stopped working for me. I've kept the GBS files on my player, in the hopes that GBS support would eventually get added/fixed. I'm so glad to see that it's finally making a comeback! Mouser X over and out.

The current NSF codec was ported from NotsoFatso, where NSFe originated (I'm pretty sure). Since you're using GME, if you do port over the NSF from GME, you would still support NSFe, right (my recollection is that GME has NSFe support, as well as the M3U support)? As for the M3U playlist loading, that's pretty cool! I, for one, would really like to see that ability added. I use NSFe files all the time, but having the ability to use the specialized M3U playlists would be great as well. Regarding VGM/VGZ support, oh PLEASE add it!!! I have a Gigabeat S60 (500 mhz CPU...), and I'd love to try it. Even if there are players that aren't fast enough to support VGM/VGZ, some of them are.... And by adding/working on it, it makes it more likely that others will work on it/optimize it for other players as well. Thank you so much for your work on GBS support! I used the old patch for a long time, until it stopped working for me. I've kept the GBS files on my player, in the hopes that GBS support would eventually get added/fixed. I'm so glad to see that it's finally making a comeback! Mouser X over and out.

Sorry about the double post.... I refreshed the page, and apparently my browser re-submitted my comment.... :(

gama commented on 2011-03-02 13:57

> Regarding VGM/VGZ support, oh PLEASE add it!!! I have a Gigabeat S60 (500 mhz CPU...), and I'd love to try it Yeah, it is the next format i will try and i'm pretty sure they will play fine in the gigabeat. But i don't think it will support VGZ files unless someone adds gzip (zip) support in rockbox.

i do remember the wiki plugin has gzip support itself, maybe you can take a look at it's code? http://www.rockbox.org/tracker/task/4755?type=4

gama commented on 2011-03-02 17:58

Oh thanks, very interesting, will take a look at it later ;). First i have to get uncompressed vgz (vgm) working.

gama commented on 2011-03-04 00:04

New nsf codec is almost finished, will upload it next week and have started working on the VGM plugin, i downloaded Pier Solar soundtrack for testing, and i have to say it has greats songs. About the gbs codec, almost finished merging the latest apu and cpu from gme6, it should fix some bugs. By the way new codecs will use the latest version of game_music_emu, i guess it's better and can work on SGC format too.

Hi there, as it stands this patch should be finalized so that it builds green on all SWCODEC platforms. Once you do that, we can commit it to SVN so that additional users can continue to help test it. You can still submit additional patches and fixes to keep improving it. It's great that you're working on so many new codecs, but let's start getting a few into SVN as well. :)

I'm still unhappy that it implements m3u playlists in the codec.

Oh, bugger off about the M3U playlist support. Come back to us when the player's core M3U parser supports storing album and track metadata for formats which are never likely to be extended to store that information themselves. Information supported by extended M3U playlists in Game_Music_Emu: Per playlist, applied globally to all tracks referenced therein: Game title, artist, composer, sequencer, engineer, ripper, tagger, and date. Per track entry: Track title, internal track number in referenced file, play length, either intro time or loop time, fade time, and repeat count.

This metadata should be read by the metadata parsers.

So the metadata parsers for the formats should be reading tags from the M3U playlist, but not by including their own playlist support?

metadata parser != codec. Yes, the metadata parsers should read the playlist if it contains the metadata for the tracks. And no, the codecs should not include their own playlist support.

argh can't get all 3 codecs to compile together >_< it outputs something like: /home/tails_/rockbox_mod/apps/plugin.c:693: warning: initialization from incompatible pointer type /home/tails_/rockbox_mod/apps/plugin.c:694: error: ‘codec_begin’ undeclared here (not in a function) /home/tails_/rockbox_mod/apps/plugin.c:695: error: ‘codec_close’ undeclared here (not in a function) (compiling uner cygwin)

gama commented on 2011-03-07 03:58

> This metadata should be read by the metadata parsers. Yes, i agree with this. But someone has to add support for the extended m3u playlists that game_music_emu uses, that way i could remove the file api requirements and the gme codecs would compile fine for all targets. I don't think it would be that hard but i don't want to mess with the rockbox core, so i hope someone else give it a try. > Hi there, as it stands this patch should be finalized so that it builds green on all SWCODEC platforms. Once you do that, we can commit it to SVN so that additional users can continue to help test it. You can still submit additional patches and fixes to keep improving it. I will upload the updated gbs codec tomorrow, the one with the latest apu and cpu from blargg, but i haven't solved the m3u playlist problem. I can remove it from the codec and it would compile fine for all targets and wait for someone to make the changes Chris Moeller explained before. Anyway i guess i will let a rockbox dev to find the best solution ;), for now playlist support will only be enabled if the target supports recording.

maybe you can combine my patch in the codec, then it should compile fine in all targets

i've made a standalone patch, this should fix compile error in gbs, hes as well as sc68 codecs on all non-recoring-targes.

gama commented on 2011-03-07 14:00

> maybe you can combine my patch in the codec, then it should compile fine in all targets Thanks i have done that ;). Here is the updated codec. Changelog: - Merged Joshua's patch to make it compile fine on all targets. - Updated gb apu and gb cpu to latest version from blargg, it should fix many bugs, but may introduce new one (s) ;). - If m3u extended metadata is found it will be displayed instead of internal one. - Fixed a bug with metadata info that used all 32 bytes from the gbs header. - Increased sound gain.

gama commented on 2011-03-07 14:02

The patch :)

Looks like it's building all green now. It's just about ready to go in to SVN, IMO. Thoughts?

"03:57:49 LambdaCalculus37 I'm looking to commit FS #11906 (GBS codec). It's building green and the m3u playlist issues appear to have been resolved, according to the comments." Where do you read that? I see nothing changed since my last comment.

the new patch's modification makes it compile fine on all targets, that's the change, if you can resolve the metadata behavior in the rb's core, welcome~

What needs to be resolved in the core?

see the author and kode54's discussion for detail, i don't think the buildin nsf's metadata behavior is perfect, as i even need to mod the nsf file's internal code to set the playback range.

What has nsf to do with this? Anyway, why not improve the metadata parser?

NSFE has sufficient data for play lengths and fade times, as well as full track titles. Here's a bunch of them: http://disch.zophar.net/nsfe.php Too bad I can't say the same about most of the other formats that GME supports. Feel free to contribute full metadata parsing to the main M3U parser.

Ok, here's my proposal again since you didn't seem to have understood it: Parse the extended m3u in the metadata parser and fill the mp3entry structure; that has nothing to do with the existing m3u parser.

And here's my response, since I guess I haven't been clear enough: Not my problem, since I'm not even getting remotely involved with Rockbox development, beyond posting subtle hints for interested developers. Maybe I would be more interested in contributing if I were remotely interested in buying a supported hardware player. For now, the only thing even approaching portable media player in my possession is a Nintendo DS Lite.

I want to be sure I understand what's going on here. Currently, the "extended M3U" data is being parsed by the codec (when it should, apparently, be parsed by the MetaData parser), correct? And, if I've read and understand the comments correctly, the current MetaData parser currently has no method to pull this "extended M3U" data (or something like that). So, for this new codec to be accepted into SVN, the "extended M3U" features would need to be removed, right? While that would work (new codec!), it significantly reduces very useful playback features. For these features to be included, the MetaData parser needs to be modified/improved to pull data from the M3U, in addition to the original files, right? I'm completely unfamiliar with the codebase of any of these things, but what, exactly, needs to be fixed/modified/improved for the "extended M3U" to work with the MetaData parser? And, if those changes were made, would it apply to all formats/codecs currently supported by Rockbox? More specifically (due to my unfamiliarity with how codecs/new formats work) if the "extended M3U" stuff is format specific (which it kind of is), what's wrong with including it in the codec? Or, how is MetaData parsing handled in other codecs? I figured that the file would be loaded into memory, and then the metadata is read from the file. GBS files and M3U playlists are separate from each other, so if that's the case (the data is read from the loaded file), it would make it difficult to use the current MetaData parser. Is there currently any codec in Rockbox, that uses external files to store additional data about the file to be played? If so, which codecs do it? If not, then what ideas does anyone have to improve/fix this issue? If that is in fact the problem (the MetaData parser is unable to look outside of the currently loaded file to be played), then it seems that really, the only method available to get "extended M3U" support would be from within the codec, as the GBS codec currently does. Obviously this can be changed (it's all software. Anything can be changed in software, if you're determined enough), but what changes would be necessary, and would it be worth it? Also, as far as I know, the best place to look for NSFe files is at http://slickproductions.org/nsfe.php (scroll down that page. It's significantly more up-to-date than Zophar's collection). If I've confused anything here (regarding support for the "extneded M3U" stuff) , please clarify it for me. Basically, I really want support for the "extended M3U" stuff, as it would make GBS files more listenable. It's not a show stopper if it's removed/excluded, but it would put a frown on my face. Mouser X over.

gama commented on 2011-03-16 14:31

> Parse the extended m3u in the metadata parser and fill the mp3entry structure; that has nothing to do with the existing m3u parser. Well i think that can be done, i remember i wanted to do it that way in the first place but there was a little problem that stopped me: i couldn't get the full path of the entry passed to the metadata parser, since the path is set after the metadata is read i guess, that could be fixed but i was too lazy to look for a solution.

MikeS commented on 2011-03-28 03:41

Just a heads up. My playback rework will do as much as initially possible to block poking values into the engine's data and all codecs that rely upon it will break (NSF is one I won't fix it all myself either since I'm spending untold hours making sure whatever core features are either unbroken or bugfixed where possible; SID still works). Further work will be done to seal it away, even from peeking except where it seems the best way to go (there are things that must be done to stop it from being fragile and racy). The codec will have its own dedicated id3 on the main audiobuffer (not ringbuffer) that doesn't exist when playback is stopped. The codec may do what it needs to with it but only it will know about it with the exception of the offset and elapsed members (which should also be nixed for live positioning purposes -- call an actual function to get that info from the playing track). In short, a proper metadata parser will be in effect, mandated. I have an inkling that if subsong support is required, then perhaps the cuesheet code can be extended and would be more intuitive than seeking.

gama commented on 2011-03-28 04:48

> In short, a proper metadata parser will be in effect, mandated. That's no problem, actually the GBS codec does have a metadata parser, the m3u playlist is only an additional feature that can be easily removed. > I have an inkling that if subsong support is required, then perhaps the cuesheet code can be extended and would be more intuitive than seeking. To extended the cuesheet code would be nice for individual subsong info, and i also think there should be a better solution for changing subsongs than seeking. I'm always open to make things better, i hope your playback rework will make rockbox a greater firmware.

gama commented on 2011-05-20 13:08

Hi, this is the updated version that works with the new playback engine (r29826). Changelog: - Removed all metadata parsing from the codec, and updated the metadata parser to handle track length. - Removed file api, and the strrchr and strcasecmp functions requirement from the codec and codec lib. - There is still support for extended m3u meta info and track remap, but the m3u is loaded by the metadata parser, not the codec. There is an issue with the elapsed time, especially when a subsong ends automatically, because it doesn't get updated correctly and this is explained by Michael at the end of this task (http://www.rockbox.org/tracker/task/12021?project=1&order=dateopened&sort=desc&pagenum=2). But it's not a major problem really. By the way, I have finished updating the other codecs as well, will upload them ASAP. Also i have ported the AY and SGC codecs from gme too.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing