Rockbox

Tasklist

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, 16:05 GMT
Last edited by Andree Buschmann (Buschel) - Monday, 04 July 2011, 05:54 GMT
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi, 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, 05:54 GMT
Reason for closing:  Duplicate
Additional comments about closing:  Replaced by FS#12176.
Comment by Robert Menes (RMenes379) - Monday, 21 March 2011, 17:28 GMT
Can you give us an explanation of how this codec works? Does it work similarly to your other codecs (it has its own metadata parser), or does it use the metadata parser in Rockbox?
Comment by MichaelGiacomelli (saratoga) - Monday, 21 March 2011, 20:01 GMT
ym2413.c is not GPL licensed as far as i can tell. Do you have permission to relicense it in a GPL project?
Comment by Mauricio Garrido (gama) - Monday, 21 March 2011, 20:54 GMT
> ym2413.c is not GPL licensed as far as i can tell. Do you have permission to relicense it in a GPL project?

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.
Comment by MichaelGiacomelli (saratoga) - Monday, 21 March 2011, 20:56 GMT
I don't think we need to close to this task. I would contact the author of that code and ask him if gme has permission to license it under the GPL.
Comment by JoshuaChang (JoshuaChang) - Tuesday, 22 March 2011, 02:42 GMT
great job! really great job!!
test codec runs around 110~120% on cowon d2+
Comment by Thomas Martitz (kugel.) - Tuesday, 22 March 2011, 08:23 GMT
What is the license of this stuff then? On blaarg's site he says all his libraries are LGPL.
Comment by PurlingNayuki (yzflcyq) - Tuesday, 22 March 2011, 12:03 GMT
Great Job too!
Test codec runs 220.05% realtime for the first time, and 230.93% realtime for a second time!
Comment by PurlingNayuki (yzflcyq) - Tuesday, 22 March 2011, 12:06 GMT
Forgot it.
I tested it on OndaVX747.
Comment by Mauricio Garrido (gama) - Tuesday, 22 March 2011, 13:27 GMT
> What is the license of this stuff then? On blaarg's site he says all his libraries are LGPL.

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.
Comment by Thomas Martitz (kugel.) - Tuesday, 22 March 2011, 13:31 GMT
Yea, that's essentially public domain except that we acknowledge him as the author; that's fine.
Comment by JoshuaChang (JoshuaChang) - Tuesday, 22 March 2011, 13:43 GMT
seems that the ym2413 was MAME license:

Files: src/emu/sound/ym2151.*,
"src/emu/sound/ym2413.*
Copyright: Jarek Burczynski
License: MAME

http://mamedev.org/legal.html
Comment by Mauricio Garrido (gama) - Tuesday, 22 March 2011, 19:24 GMT
According to the MAME license, code obtained from it can be redistributed if the MAME copyright
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.
Comment by MichaelGiacomelli (saratoga) - Tuesday, 22 March 2011, 19:26 GMT
>According to the MAME license, code obtained from it can be redistributed if the MAME copyright
>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

Comment by Mauricio Garrido (gama) - Tuesday, 22 March 2011, 21:49 GMT
Thanks i understand now, then will have to use another 2612 emu too.
Comment by JoshuaChang (JoshuaChang) - Thursday, 24 March 2011, 07:53 GMT
i've found a problem:
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+
Comment by Mauricio Garrido (gama) - Thursday, 24 March 2011, 22:24 GMT
> 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.

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.
Comment by JoshuaChang (JoshuaChang) - Friday, 25 March 2011, 00:14 GMT
after some further test, i do think the high cpu usage+metadata parser was the freezer, the freeze possibility was decreased since i tune on the O3 switch.

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.
Comment by Mauricio Garrido (gama) - Saturday, 26 March 2011, 00:45 GMT
I have confirmed that compiling the codecs with -O3 results in a noticeable increase
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.
Comment by JoshuaChang (JoshuaChang) - Saturday, 26 March 2011, 10:48 GMT
eh~ what about your fuze v2's vgm codec speed? and which file got 80% performance gain?
Comment by Mauricio Garrido (gama) - Monday, 28 March 2011, 04:54 GMT
Well, i got ~140% realtime speed in the sansa. And actually i was talking about all gme codecs in general,
in got that gain with the GBS codec with using some Megaman Xtreme2 track.
Comment by JoshuaChang (JoshuaChang) - Thursday, 31 March 2011, 06:13 GMT
eh~ how to run test_codec in single-file-multi-track music(gbs/nsf/hes)?
ps, i've confirmed the freeze issue was related to file buffering system, not the codec itself.
Comment by Mauricio Garrido (gama) - Saturday, 02 April 2011, 03:01 GMT
> eh~ how to run test_codec in single-file-multi-track music(gbs/nsf/hes)?

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.
Comment by Postolati Maxim (tails_) - Thursday, 07 April 2011, 11:00 GMT
JoshuaChang, The real freezer is decoding process+buffering thread
-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 >_>
Comment by JoshuaChang (JoshuaChang) - Thursday, 07 April 2011, 14:00 GMT
yeah~ i've written a patch to force flush the buffer when trying to change gme songs in file browser, that works
Comment by Postolati Maxim (tails_) - Friday, 08 April 2011, 09:12 GMT
Can you put it somewhere?
Comment by JoshuaChang (JoshuaChang) - Monday, 11 April 2011, 14:34 GMT
seems svn r29697 slove the buffer issue in a better way~ need more tests...
Comment by JoshuaChang (JoshuaChang) - Tuesday, 12 April 2011, 07:42 GMT
well, after some further test, the r29697 still freeze...
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.
Comment by Michael Sevakis (MikeS) - Thursday, 21 April 2011, 12:24 GMT
Hrm....LOL...I actually wanted to do this one myself. I'll give it a tryout.
Comment by Michael Sevakis (MikeS) - Thursday, 21 April 2011, 16:01 GMT
Been playing nicely for awhile, with a few lines changed to work with the playback patch (not the metadata poking part which won't work there), which only took a couple of minutes to do. Definitely needs trimming and optimizing (some native asm in hotspots most surely) since it's a bit CPU hungry even on the beast (about equal to the -c4000 .ape files I have @220-230 MHz in the buffering screen), ~300% realtime or so in test_codec (~175MHz).
Comment by JoshuaChang (JoshuaChang) - Wednesday, 27 April 2011, 05:47 GMT
could you post the modified patch?i've no idea on how to mod the codec to work with the new playback engine(i have the gbs/hes/sc68/vgm, as well as the new nsf patch installed)
Comment by Michael Sevakis (MikeS) - Thursday, 28 April 2011, 04:14 GMT
With the basic codec conversion. Nothing was touched for handling VGZ.
Comment by Mauricio Garrido (gama) - Saturday, 30 April 2011, 00:02 GMT
Could someone explain the advantages of the new playback engine? I have been using rockbox for a while and
didn't have any problem with the old one.
Comment by Mauricio Garrido (gama) - Saturday, 30 April 2011, 00:16 GMT
Nevermind, i found the original task and i have to say it has a lot of pros :0. I will see if i can make the other
gme codecs to work with it ;).
Comment by JoshuaChang (JoshuaChang) - Saturday, 30 April 2011, 13:01 GMT
gama, i've made hes to get to work, but due to the new playback engine's behavior, the seekbar seems never changed when a sub-track was auto ended(like the official nsf)...
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~
Comment by Michael Sevakis (MikeS) - Saturday, 30 April 2011, 13:49 GMT
What happens is that the current position is latency adjusted and always has been. Setting the CP while PCM is full sutracts about 3s from the time. I'm trying to rework the way times are updated, meaning adding timestamps to PCM. Codecs may not even need modification (we'll see). Latency would be irrelevant, a codec may stamp its samples any way it likes and playback wouldn't touch them.

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.
Comment by Mauricio Garrido (gama) - Friday, 10 June 2011, 00:52 GMT
Oh man, could a mod delete the previous three atachments and comments?, they are wrong or incomplete.
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
Comment by JoshuaChang (JoshuaChang) - Tuesday, 14 June 2011, 02:54 GMT
synced, waiting for your new gme codecs
Comment by Mauricio Garrido (gama) - Friday, 24 June 2011, 02:57 GMT
Sorry for the lack of updates Joshua i am working on a new patch that will contain all gme codecs,
it's almost complete and i believe it will be easier to maintain that way ;).
Comment by PurlingNayuki (yzflcyq) - Monday, 27 June 2011, 02:07 GMT
I apply the patch and try to compile OndaVX747 target. Though I can compile it successfully, it doesn't work at all. When I try to play a VGM file, my DAP show the WPS but runs very slowly. And there's no sound enev though I set the volume to 0dB (max volume).
Hope you can solve the problem, thanks.
Comment by Mauricio Garrido (gama) - Wednesday, 29 June 2011, 16:48 GMT
Hi Nayuki, i will upload a new patch that contains all the ported game_music_emu codecs. I am replacing all the MAME code with
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.
Comment by Thomas Martitz (kugel.) - Wednesday, 29 June 2011, 16:48 GMT
Well, ideally we want this in SVN so no patch needs to be maintained :)
Comment by Mauricio Garrido (gama) - Wednesday, 29 June 2011, 21:53 GMT
Yeah, you are right ;). It seems i managed to replace all code taken from MAME with GPL'd emus, so i hope
it can make it to the SVN now ;). Just need to clean the code a bit and i will upload the new patch ASAP.
Comment by PurlingNayuki (yzflcyq) - Thursday, 30 June 2011, 12:22 GMT
Hello Garrido. I tried your vgm v0.3c and vgm 0.2 but they don't work at all. Where is your new patch?
Comment by JoshuaChang (JoshuaChang) - Thursday, 30 June 2011, 13:40 GMT
if both version failed to work, then i think this was related to new playback engine, maybe it eat too much iram...

Loading...