Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Mauricio Garrido (gama) - Wednesday, 26 January 2011, 15:35 GMT
Last edited by Andree Buschmann (Buschel) - Monday, 04 July 2011, 05:53 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

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.

This task depends upon

Closed by  Andree Buschmann (Buschel)
Monday, 04 July 2011, 05:53 GMT
Reason for closing:  Duplicate
Additional comments about closing:  Replaced by FS#12176.
Comment by Maurus Cuelenaere (mcuelenaere) - Wednesday, 26 January 2011, 19:02 GMT
You seem to have forgotten to attach the patch.
Comment by Mauricio Garrido (gama) - Wednesday, 26 January 2011, 20:06 GMT
Oh, sorry.
Comment by Thomas Martitz (kugel.) - Thursday, 27 January 2011, 15:43 GMT
The Game_Music_Emu library seems to support a lot more formats. Is there a reason you only ported gameboy sounds over?
Comment by Mauricio Garrido (gama) - Thursday, 27 January 2011, 21:31 GMT
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.
Comment by JoshuaChang (JoshuaChang) - Friday, 28 January 2011, 01:58 GMT
is it possible to port the vgm(vgz) format support? it will be great if rockbox can playback megadrive's music!
Comment by Mauricio Garrido (gama) - Friday, 28 January 2011, 15:09 GMT
The vgm tunes usually are too cpu demanding, due to the use of several sound chips at the same time, i remember even on
the 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 on
the 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.

Comment by JoshuaChang (JoshuaChang) - Friday, 28 January 2011, 15:19 GMT
well~ the hes is another awesome game music format!
Comment by Alejandro Arellano (Vague Rant) - Saturday, 05 February 2011, 12:13 GMT
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.
Comment by Mauricio Garrido (gama) - Monday, 07 February 2011, 03:57 GMT
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 as
i 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 ;).
Comment by Mauricio Garrido (gama) - Thursday, 10 February 2011, 14:37 GMT
Hi, i have updated the gbs codec, it seems the bug mentioned above is fixed.

Changelog:

- 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.
Comment by Thomas Martitz (kugel.) - Thursday, 10 February 2011, 14:49 GMT
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.
Comment by Alejandro Arellano (Vague Rant) - Friday, 11 February 2011, 01:12 GMT
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.
Comment by Thomas Martitz (kugel.) - Friday, 11 February 2011, 02:11 GMT
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.
Comment by Alejandro Arellano (Vague Rant) - Sunday, 13 February 2011, 05:57 GMT
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 Theme,0:05:15,,0:00:05,
Pop 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.
Comment by Postolati Maxim (tails_) - Sunday, 13 February 2011, 20:10 GMT
http://pastebin.com/raw.php?i=f5tBEKs7 Having an error while compiling. used r29290
http://pastebin.com/raw.php?i=bfD71byj there was also errors while patching so i edidted metadata.h and metadata.c manualy
Comment by JoshuaChang (JoshuaChang) - Monday, 14 February 2011, 00:04 GMT
try this patched file
Comment by Postolati Maxim (tails_) - Monday, 14 February 2011, 01:21 GMT
It compiles fine but playback fails showing "Undefined instruction at 21E7F508"
Comment by JoshuaChang (JoshuaChang) - Monday, 14 February 2011, 01:44 GMT
eh...forget it, i'll try to fix it once more...
Comment by Mauricio Garrido (gama) - Monday, 14 February 2011, 14:08 GMT
Oh, i used 29139, but rockbox is a very active project. Should i make the HES patch based on the latest revision?
Comment by Postolati Maxim (tails_) - Monday, 14 February 2011, 14:09 GMT
yup better to do that
Comment by Mauricio Garrido (gama) - Monday, 14 February 2011, 16:02 GMT
And about the file open, read, etc, it seems they are only defined in devices that support recording,
maybe it would be easier to define them for all targets?.
Comment by Postolati Maxim (tails_) - Tuesday, 15 February 2011, 01:24 GMT
dunno
Comment by JoshuaChang (JoshuaChang) - Wednesday, 16 February 2011, 05:10 GMT
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 file?
modified files attached, for gbs as well as hes
Comment by JoshuaChang (JoshuaChang) - Wednesday, 16 February 2011, 08:05 GMT
fix: remove redefinition
Comment by Mauricio Garrido (gama) - Thursday, 17 February 2011, 03:11 GMT
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 file?
modified 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.

Comment by Mauricio Garrido (gama) - Thursday, 17 February 2011, 03:13 GMT
I forgot to post the patch :)
Comment by JoshuaChang (JoshuaChang) - Thursday, 17 February 2011, 08:10 GMT
i've made a mistake, the m3u was auto loaded when i play the gbs/hes files...it's ok!
ps:the strchr and strcasecmp can be placed in the struct wherever you want, the old location also worked.
Comment by Mauricio Garrido (gama) - Thursday, 17 February 2011, 15:27 GMT
> 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.
Comment by Robert Menes (RMenes379) - Friday, 18 February 2011, 11:31 GMT
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 'Gbs_load_m3u':
/Users/rmenes/rockbox/apps/codecs/libgbs/m3u_playlist.c:398: error: 'struct codec_api' has no member named 'open'
/Users/rmenes/rockbox/apps/codecs/libgbs/m3u_playlist.c:405: error: 'struct codec_api' has no member named 'read'
/Users/rmenes/rockbox/apps/codecs/libgbs/m3u_playlist.c:406: error: 'struct codec_api' has no member named 'close'
make: *** [/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.
Comment by Postolati Maxim (tails_) - Saturday, 19 February 2011, 06:14 GMT
>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
Comment by Chris Moeller (kode54) - Tuesday, 22 February 2011, 09:52 GMT
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.
Comment by Chris Moeller (kode54) - Tuesday, 22 February 2011, 09:54 GMT
And yes, that version does fix the timing issues with Pokémon Red/Blue.
Comment by Mauricio Garrido (gama) - Monday, 28 February 2011, 15:19 GMT
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.
Comment by Postolati Maxim (tails_) - Tuesday, 01 March 2011, 19:32 GMT
>vrc7 songs
Holly smoke finally we will be able to fully enjoy homebrew NES music :*)
Comment by Marvin Miller (Mouser X) - Tuesday, 01 March 2011, 22:33 GMT
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.
Comment by Marvin Miller (Mouser X) - Tuesday, 01 March 2011, 23:20 GMT
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.
Comment by Marvin Miller (Mouser X) - Tuesday, 01 March 2011, 23:22 GMT
Sorry about the double post.... I refreshed the page, and apparently my browser re-submitted my comment.... :(
Comment by Mauricio Garrido (gama) - Wednesday, 02 March 2011, 13:57 GMT
> 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.
Comment by JoshuaChang (JoshuaChang) - Wednesday, 02 March 2011, 14:15 GMT
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
Comment by Mauricio Garrido (gama) - Wednesday, 02 March 2011, 17:58 GMT
Oh thanks, very interesting, will take a look at it later ;). First i have to get uncompressed vgz (vgm) working.
Comment by Mauricio Garrido (gama) - Friday, 04 March 2011, 00:04 GMT
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.
Comment by Robert Menes (RMenes379) - Saturday, 05 March 2011, 12:34 GMT
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. :)
Comment by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 12:39 GMT
I'm still unhappy that it implements m3u playlists in the codec.
Comment by Chris Moeller (kode54) - Saturday, 05 March 2011, 13:08 GMT
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.
Comment by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 13:35 GMT
This metadata should be read by the metadata parsers.
Comment by Chris Moeller (kode54) - Saturday, 05 March 2011, 14:00 GMT
So the metadata parsers for the formats should be reading tags from the M3U playlist, but not by including their own playlist support?
Comment by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 14:04 GMT
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.
Comment by Postolati Maxim (tails_) - Saturday, 05 March 2011, 17:05 GMT
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)
Comment by Mauricio Garrido (gama) - Monday, 07 March 2011, 03:58 GMT
> 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.
Comment by JoshuaChang (JoshuaChang) - Monday, 07 March 2011, 04:09 GMT
maybe you can combine my patch in the codec, then it should compile fine in all targets
Comment by JoshuaChang (JoshuaChang) - Monday, 07 March 2011, 08:14 GMT
i've made a standalone patch, this should fix compile error in gbs, hes as well as sc68 codecs on all non-recoring-targes.
Comment by Mauricio Garrido (gama) - Monday, 07 March 2011, 14:00 GMT
> 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.




Comment by Mauricio Garrido (gama) - Monday, 07 March 2011, 14:02 GMT
The patch :)
Comment by Robert Menes (RMenes379) - Tuesday, 15 March 2011, 02:56 GMT
Looks like it's building all green now. It's just about ready to go in to SVN, IMO.

Thoughts?
Comment by Thomas Martitz (kugel.) - Tuesday, 15 March 2011, 09:11 GMT
"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.
Comment by JoshuaChang (JoshuaChang) - Tuesday, 15 March 2011, 10:19 GMT
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~
Comment by Thomas Martitz (kugel.) - Tuesday, 15 March 2011, 10:33 GMT
What needs to be resolved in the core?
Comment by JoshuaChang (JoshuaChang) - Tuesday, 15 March 2011, 10:49 GMT
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.
Comment by Thomas Martitz (kugel.) - Tuesday, 15 March 2011, 10:51 GMT
What has nsf to do with this? Anyway, why not improve the metadata parser?
Comment by Chris Moeller (kode54) - Tuesday, 15 March 2011, 10:56 GMT
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.
Comment by Thomas Martitz (kugel.) - Tuesday, 15 March 2011, 11:10 GMT
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.
Comment by Chris Moeller (kode54) - Tuesday, 15 March 2011, 11:35 GMT
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.
Comment by Marvin Miller (Mouser X) - Tuesday, 15 March 2011, 21:28 GMT
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.
Comment by Mauricio Garrido (gama) - Wednesday, 16 March 2011, 14:31 GMT
> 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.

Comment by Michael Sevakis (MikeS) - Monday, 28 March 2011, 03:41 GMT
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.
Comment by Mauricio Garrido (gama) - Monday, 28 March 2011, 04:48 GMT
> 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.


Comment by Mauricio Garrido (gama) - Friday, 20 May 2011, 13:08 GMT
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...