This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12021 - New VGM (Video Game Music) codec based on Game_Music_Emu ;)
Attached to Project:
Rockbox
Opened by Mauricio Garrido (gama) - Monday, 21 March 2011, 17:05 GMT+2
Last edited by Andree Buschmann (Buschel) - Monday, 04 July 2011, 07:54 GMT+2
Opened by Mauricio Garrido (gama) - Monday, 21 March 2011, 17:05 GMT+2
Last edited by Andree Buschmann (Buschel) - Monday, 04 July 2011, 07:54 GMT+2
|
DetailsHi, this is a new VGM (Video Game Music) codec based on blargg's
Game_Music_Emu library. More info here: http://en.wikipedia.org/wiki/VGM_(file_format) Tested on: Sansa Fuze v2 Created from revision: 29607 Features: - 44 khz, stereo output. - Support for VGZ files (Note 1) using the inflate code from WikiViewer plugin by Adam Gashlin. - Support for SN76489/SN76496 PSG, YM2612, and YM2413 FM sound chips. - Track seeking (very slow). - Based on the latest version of game_music_emu. Note 1: Many VGZ files will be trimmed when trying to uncompress them due to the small amount of free memory available to the codecs with codec_malloc (around 900 Kb). So it is recommended to use uncompressed VGM files. * If your target has a large RAM (like the cowon d2) i guess you can try setting the CODEC_SIZE define to a bigger value like 5-6 MB, that way most vgz files will work fine. |
This task depends upon
Closed by Andree Buschmann (Buschel)
Monday, 04 July 2011, 07:54 GMT+2
Reason for closing: Duplicate
Additional comments about closing: Replaced by FS#12176.
Monday, 04 July 2011, 07:54 GMT+2
Reason for closing: Duplicate
Additional comments about closing: Replaced by FS#12176.
Mmm, certainly not. I wasn't aware of that since it was included in gme6pre. I will try to contact the author of the ym2413 emu for
permission.
But for now i don't want to give blargg, the author of gme, any trouble so if anyone think it is necessary i ask a moderator
to delete this task (or just the patch) and also the nsf one since it uses the ym2413 emu too. I could reupload both codecs without the ym2413 emu later.
P.S. I don't have much experience with open source projects, so if anyone can tell me what is the
best solution for this case please let me know.
test codec runs around 110~120% on cowon d2+
Test codec runs 220.05% realtime for the first time, and 230.93% realtime for a second time!
I tested it on OndaVX747.
The problem is the ym2413 emu which is not from blargg, but from Jarek Burczynski, a dev from MAME.
I tryied to contact him but the mail address i got is no longer active.
But i think i found a solution, there is another 2413 emu written by Mitsutaka Okazaki. He gives permission
to redistribute his emu under a simple condition: 'if the origin of this software is not misrepresented'.
His emu has been redistributed with other open source projects, including some with the GPL license like
smsplus with no problem.
Files: src/emu/sound/ym2151.*,
"src/emu/sound/ym2413.*
Copyright: Jarek Burczynski
License: MAME
http://mamedev.org/legal.html
notice and the author rights are included in the code as blargg did with the ym2612 emu. Then i think it's ok to use Jarek's
ym2413 emu just have to put the copyright notice there too.
Either way i managed to merge Mitsutaka emu, and i kinda like it better. But will upload it so anyone can help
to choose one of them.
>notice and the author rights are included in the code as blargg did with the ym2612 emu.
MAME code cannot be used in GPL projects, the MAME license is intentionally incompatible:
http://en.wikipedia.org/wiki/MAME#MAME_license
while playing a vgm file, if i try to switch to another vgm file(in another directory, certainly no in playlist), it has a large possibility of freezing the whole system.
ps:switch to -O3 optimization flag can obtain up to 15% performance gain! tested in cowon d2+
I have been playing several tracks in different folders and haven't found that problem in the sansa, but there is a bit slowdown when changing from one file to another. Do you have a lot of
files in the same folder?. One cause must be the high cpu usage, i have found a similar behavior with some spc songs, and other may be the metadata parser.
> switch to -O3 optimization flag can obtain up to 15% performance gain! tested in cowon d2+
That's interesting, what do you do to obtain a codec performance measure?. Maybe i can try with the other codecs too,
i haven't made any benchmarking in the codecs actually.
about the codec performance: compile the target with test plugins support, then you can open the vgm files using test codec plugin and do the performance test.
in performance in the sansa (arm cpu), around 15% to 80% in the test_codec speed results.
The only drawback is that the codec size increases as well, but i think it's worth it.
in got that gain with the GBS codec with using some Megaman Xtreme2 track.
ps, i've confirmed the freeze issue was related to file buffering system, not the codec itself.
I had to modify the codecs to work; I removed the m3u loading stuff and changed it to play
only one subsong, and to properly set the elapsed time.
-O3 flag also does noticeable speedup for NSF codec (noticable then thack uses VRC7 along with other chips)
//yay finally awaken after 3(?) weeks of playing VNs >_>
here is my rough patch, just force flush the buffer when select songs in file browser && current playing song is gme type,
side effect: lost fade in/out effect if buffer was flushed.
didn't have any problem with the old one.
gme codecs to work with it ;).
i'll upload it soon and maybe you can find a workaround~~
btw: in the new playback engine, the tag infos as well as the track's length must be set in the metadata stage, codec can not do it anymore, so you may need to move the m3u reading/nsf length/gbs reading into metadate stage, just a small advice~
Also, I'd like to have general-purpose support for multitrack files (which is not limited to game music emulators, afaik but includes some oggs as well). I feel like this can also serve to incorporate MIDI and even wavpack hybrid if executed well.
Also, pushing metadata up may come back, however must be done in a way that playback knows about what's happening so as not to corrupt internal states because the codec cannot really know which track is being displayed to the user and shouldn't have to worry about that.
I shouldn't do this being a little tired ;). Please use this patch.
By the way i'm looking for a ym2612 emu that can be used with gpl, anyone knows one?. I found
one from Stéphane Dallongeville used in an older revision from genplus-gx, but i'm not sure if it uses
the gpl license.
Edit by Michael Sevakis: Previous three comments deleted per user request
it's almost complete and i believe it will be easier to maintain that way ;).
Hope you can solve the problem, thanks.
other that is already under the GPL license. For now can you compile the patch for the simulator and see if it works?.
Sorry if this is taking some time, but i guess it will be better to maintain only one patch. By the way the new patch will include the remaining formats as well: ay, kss and sgc.
it can make it to the SVN now ;). Just need to clean the code a bit and i will upload the new patch ASAP.