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-03-21
Last edited by Buschel - 2011-07-04

FS#12021 - New VGM (Video Game Music) codec based on Game_Music_Emu ;)

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:

  1. 44 khz, stereo output.
  2. Support for VGZ files (Note 1) using the inflate code from

WikiViewer plugin by Adam Gashlin.

  1. Support for SN76489/SN76496 PSG, YM2612, and YM2413 FM sound chips.
  2. Track seeking (very slow).
  3. 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.

Closed by  Buschel
2011-07-04 05:54
Reason for closing:  Duplicate
Additional comments about closing:  

Replaced by FS#12176.

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?

ym2413.c is not GPL licensed as far as i can tell. Do you have permission to relicense it in a GPL project?

gama commented on 2011-03-21 20:54
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

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.

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.

great job! really great
codec runs around 110~120% on cowon d2+

What is the license of this stuff then? On blaarg’s site he says all his libraries are LGPL.

Great Job
codec runs 220.05% realtime for the first time, and 230.93% realtime for a second time!

Forgot
tested it on OndaVX747.

gama commented on 2011-03-22 13:27
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
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
with no problem.

Yea, that’s essentially public domain except that we acknowledge him as the author; that’s fine.

seems that the ym2413 was MAME license:

Files: src/emu/sound/ym2151.*,
Jarek
MAME

http://mamedev.org/legal.html

gama commented on 2011-03-22 19:24

According to the MAME license, code obtained from it can be redistributed if the MAME
and the author rights are included in the code as blargg did with the ym2612 emu. Then i think it’s ok to use
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.

According to the MAME license, code obtained from it can be redistributed if the MAME
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

gama commented on 2011-03-22 21:49

Thanks i understand now, then will have to use another 2612 emu too.

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+

gama commented on 2011-03-24 22:24

> 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
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.

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.

gama commented on 2011-03-26 00:45

I have confirmed that compiling the codecs with -O3 results in a noticeable
performance in the sansa (arm cpu), around 15% to 80% in the test_codec speed
only drawback is that the codec size increases as well, but i think it’s worth it.

eh~ what about your fuze v2’s vgm codec speed? and which file got 80% performance gain?

gama commented on 2011-03-28 04:54

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.

eh~ how to run test_codec in single-file-multi-track
i’ve confirmed the freeze issue was related to file buffering system, not the codec itself.

gama commented on 2011-04-02 03:01
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
one subsong, and to properly set the elapsed time.

JoshuaChang, The real freezer is decoding process+buffering
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 >_>

yeah~ i’ve written a patch to force flush the buffer when trying to change gme songs in file browser, that works

Can you put it somewhere?

seems svn r29697 slove the buffer issue in a better way~ need more tests...

well, after some further test, the r29697 still
is my rough patch, just force flush the buffer when select songs in file browser && current playing song is gme
effect: lost fade in/out effect if buffer was flushed.

MikeS commented on 2011-04-21 12:24

Hrm....LOL...I actually wanted to do this one myself. I’ll give it a tryout.

MikeS commented on 2011-04-21 16:01

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).

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)

MikeS commented on 2011-04-28 04:14

With the basic codec conversion. Nothing was touched for handling VGZ.

gama commented on 2011-04-30 00:02

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.

gama commented on 2011-04-30 00:16

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 ;).

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~

MikeS commented on 2011-04-30 13:49

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.

gama commented on 2011-06-10 00:52

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

synced, waiting for your new gme codecs

gama commented on 2011-06-24 02:57

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 ;).

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.

gama commented on 2011-06-29 16:48

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.

Well, ideally we want this in SVN so no patch needs to be maintained :)

gama commented on 2011-06-29 21:53

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.

Hello Garrido. I tried your vgm v0.3c and vgm 0.2 but they don’t work at all. Where is your new patch?

if both version failed to work, then i think this was related to new playback engine, maybe it eat too much iram…

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing