Forums

A Winamp-like wave dumper should be quite easy. I'll put that on my todo list.
Playlists are planned, too.

Would there be any big problem with also adding a "logging rate" field to this version of the format? Normal VGM files use a rate of 44100 Hz. This would allow setting the rate, for example, to the sampling rate of the FM chip (e.g. 53267.0454545...), so that writes occur during the same FM samples as they originally did. It could be expressed as a rational value, allowing exact representations of the actual FM rate. Just an idea, anyway.

That might be a good way to bolt on "super-accurate timing" to the format. (Redoing the whole thing from scratch would be even better, there are so many mistakes in the format...)

I'm mostly of the opinion that the dominant player gets to define the standard for things like this (for better or worse). If someone can come along and make a decent replacement for in_vgm I'd be happy to give it up to be honest.

VGM Player with DiskWriter function
http://www.mediafire.com/?jvdyuujdimd

The ini-file is now well documented, so look into it.
You can pause or fade (key 'F') the music even if there's no sound.

In my opinion a "logging rate" should be a feature of vgm v2. Every chip has its own sample rate, so this is almost impossible with the current version.
But it may be a good idea to think about vgm v2.

Yeah, I was just thinking of a simple approach to solve possible issues with FM writes being slightly too early or late as the current VGM timing can cause. I don't know a lot about how the FM chips work, and whether writes to them can be timing-sensitive such that a write being one FM sample earlier or later can make a large difference in the sound; I'd love to find out that it's not that sensitive. Hopefully the main problem we've been having with FM music is due merely to not running the FM chips at their proper rates.

The idea was that there is probably only one FM sound chip used by a given song (or if multiple FM chips, they are of the same sample rate and synchronized), so that all the FM writes could be at the proper times without needing multiple rates. PSG writes wouldn't be exact, but the PSG isn't super-sensitive to write times.

I agree that a version 2 should either allow a "sample" rate in the tens of MHz, and derive each sound chip's clock by dividing it by an integer. You could do this even with the current format, but the added entropy in the delays would probably bloat files a lot. The other approach of course is to have separate streams for each sound chip, each stream having its own clock rate (if someone can write a player with keeps each stream properly synchronized and all, not an easy task).

Oh, and a small error in the VGM specs that's been nagging me: for the YM2612 clock rate field, it says "Input clock rate in Hz for the YM2612 chip. A typical value is 3579545", even though the YM2612 typically runs at a rate almost double that. The 1.51 spec seems to possibly extend this error to the new FM chips as well.

Blargg wrote

Yeah, I was just thinking of a simple approach to solve possible issues with FM writes being slightly too early or late as the current VGM timing can cause. I don't know a lot about how the FM chips work, and whether writes to them can be timing-sensitive such that a write being one FM sample earlier or later can make a large difference in the sound; I'd love to find out that it's not that sensitive.

In theory, you need to be accurate to the very clock cycle of the original chip, as the combinatorial nature of the synthesis (feedback, modulation, etc) means it *might* be highly sensitive to these in certain cases.

Specifying the master clock as an integer multiple of all the chips' clocks is one option, but as you said that makes the pause lengths larger numbers. That's an issue regardless.

Blargg wrote

I agree that a version 2 should either allow a "sample" rate in the tens of MHz, and derive each sound chip's clock by dividing it by an integer.

I think the best approach would be to have one "sample rate" per chip stream. VGM as designed has a reasonably front-to-back ordering (no seeking and only one file pointer required for basic playback), but if we let that go out the window then there's no reason not to, for example, have one stream for the wait lengths and another for the chip writes, and save all the overhead of using a leading byte for every "command". The difficulty comes from emulator support (for them it's easiest if they can dump a header, then a byte or three for every chip write, then maybe a bit of header fixup when logging stops). So the format ought to support an interleaved stream to make that easier; conversion between the two ought to be easily testable for the support tools. Optvgm is a great example of this stream splitting and postprocessing.

Blargg wrote

(if someone can write a player with keeps each stream properly synchronized and all, not an easy task).

I don't see that it's a great difficulty. Effectively you have multiple one-chip player mixing their outputs, they just happen to share a file on disk.

Blargg wrote

Oh, and a small error in the VGM specs that's been nagging me: for the YM2612 clock rate field, it says "Input clock rate in Hz for the YM2612 chip. A typical value is 3579545", even though the YM2612 typically runs at a rate almost double that. The 1.51 spec seems to possibly extend this error to the new FM chips as well.

Hmm, that's quite horribly wrong :) I fixed the one at http://www.smspower.org/music/uploads/Help/vgmspec150.txt .

I went through a lot of MAME's driver files and corrected some clock rates. 3579545 is good for the YM3526 and YM3812.
The corrected spec. is attached.

I recently looked into the Gens source code and I may or may not add the SegaCD PCM chip (RF5C164), so the current spec 1.51 is something beta-like.

EDIT: Oops, I forgot to attach the file.

vgmspec151.txt (13.58 KB)

VGM spec 1.51 clock rate fix

If you decide to implement the SCD PCM, I would recommend you use Gens/GS as a source.

Maxim wrote

I'm mostly of the opinion that the dominant player gets to define the standard for things like this (for better or worse). If someone can come along and make a decent replacement for in_vgm I'd be happy to give it up to be honest.

I think it's defined by anyone who manages to dump a lot of games in a particular format. If the dumps are better than the previous format, or are of lots of previously-undumped/undumpable games, then player authors will naturally write code to play them back.

I have worked on my VGM Player a lot.

New features are:
- a Linux port
- Playlist support
- Seeking Forward/Backward
- for owners of a soundcard with OPL chip: FM hardware emulation (including seeking)
(I have a Soundblaster 16)

For more info you can read the readme file.
Here's the player: http://www.mediafire.com/?y0lzdjkruz2
VGMPlay.exe is for Windows and VGMPlay for OpenSUSE.

And the full source code: http://www.mediafire.com/?mxwndj32jwm
It compiles with MS VC++ 6 and GNU make (tested with OpenSuse).

To show the power of Hardware FM, I recorded some pieces of music.
http://www.mediafire.com/?sharekey=35dd0dea0623d548aaca48175a79d1c355fec1fd8b138836a4648785df63f216
There is the Cave Theme from Phantasy Star which lets you hear the difference between Meka's OPL Mapper and my custom one.
Space Harrier Theme shows two things:
1. my OPL Mapper for the PSG sound chip
2. a common bug of many early YM2413 VGMs (just listen to "New" at 0:26 and "old" at 0:06")
This happens when an instrument change is sent after a note was set on, because the commands are sorted. (NoteOn: 0x20, InstrumentChange: 0x30)
You may not hear a difference with any software emulator, because both messages are sent before a sample is generated. That's not the case on real hardware and playing such vgms on a real SMS can produce the same bug.

OK, enough words.
Have fun!

EDIT: Link update because of small bugfix

Hi everybody. I love this web! I have thousands of files in my psp! ( mame vgm's doesn't work yet in Game Music Gear... ok I won't beg )

First of all, may be somebody finds this usefull:
I managed to rip "snow bross" music in a strange way. The game uses ym3812 aka OPL chip (the same as sound blaster 16/adlib).
I got an old mame for ms-dos (0.32). this version can use the ym3812 from the sound blaster to reproduce music. I loaded mame using Dosbox.
Dosbox can rip "raw OPL data"... I got perfect rips from the game in .dro format (dosbox raw opl), you can play .dro with adplug plugin.

I know this web is for the VGM but I think this could be usefull for some mame games.

I upload the .dro files :)

Going back to VGM's... I want to rip some vgm's from neo geo roms but they are not working with this mamevgm, :( , I don't know... I'd be happy just with puzzle bobble vgm's I love that game. If somebody gets pbobble working with mamevgm, please tell me.

Forgive me for my bad English.

Snow bross - Dosbox Raw OPL rip .zip (21.52 KB)

Ripped with Dosbox

MAME VGM should support pbobble and NeoGeo ROMs. I'm sure the version from January had YM2610 support, but I don't know.
Here's a link to the lastest version of MAME VGM:
http://www.mediafire.com/?8t71gtqzdhvcrsp
I tested pbobble and it worked.

And for Snow Bros:
You can make vgms with MAME VGM. That's more accurate. (dro: 1000 Hz, vgm: 44100 Hz)
And AdPlug for Winamp doesn't play these dro files (they are dro version 2). So I use my own VGM Player instead which supports dro files, too (in v0, v1 and v2).

And btw: I have complete rip of Lemmings DOS in dro format on my HD. I haven't made a good dro2vgm yet, but it's coming soon.

Well these .dro files play at 44100 Hz in GMGear (PSP), but you are right, VGM is better because .dro files are not always played very well.

Mamevgm keeps complaining "no chd images" I'm missing something ??.

edit: ups bad romset.. problem solved! now I'll try vgm tools to optimize the music! the intro tune is 2 MB! and I have to find if puzzle bobble has a test menu to play the music without ingame sounds :)

pbobble has a test menu by pressing F2. pbobbleN doesn't.
I checked that when I tested these sets.

And EVERY tune has a 2 MB Sample-ROM (pbobble, it's 7 MB for pbobblen).
After trimming/tagging the files you can send them to me and I'll see how to optimize the ROM data.

I just noticed that vgm_trim strips the Sample-ROM. So the trimmed files are much smaller, but lack drums and speech. I'll fix that.

I ripped all the tunes (not the short sound effects), each VGM is 2.0 - 2.2 MB.
Ingame, 2 Players and continue tunes are trimmed.
If the unused ADPCM data is deleted (How?) the size should be much smaller.
They play very well in VGMPlay, in_vgm plugin doesn't play them at all (winamp).

Edit: Thanks Tom I'm using linux and I don't use zip files, I couldn't upload a 7z (600 K).
Anyway these files are not optimized... hope they will... and we won't need to compress them :) I think each tune would be 160 Kb or less without all unused samples

Puzzle Bobble.rar (795.9 KB)

I love Puzzle Bobble, thanks for the rip!
By the way, your RAR file is huge because you made a standard RAR file. Since all those songs share samples between eachother, a solid RAR file would have been much more effective.
Your file is 4.72MB, once recompressed in a solid RAR file it becomes 795kB.
Download it here.

...VGM7z is designed for that sort of thing.

I always thought that 200 KB is too small for a VGM7z pack.

The Puzzle Bobble rip sounds nice, but I noticed that the vgms were rounded to frames. This may be fine for SMS and some other consoles, but I experienced that it's very uncommon for arcade games to be frame-accurate. So I would avoid to round arcade music in general. (I think that OutRun had an accuracy of 110-120 frames or so.)
I think that there are 2 tunes missing: 24 (ingame without intro) and 28.

I'll use these files to write a new tool since I don't want to do that by hand too many times.
Btw: When I stripped unused samples from OutRun vgms, I used my vgm player to create a mask of used data-bytes. I think some parts are still in the source code.

Well I used vgm facc with two of the songs, just to test and the size was a bit smaller.
I used load/save state in the test menu to rip one by one, whith a little silence at the beggining. I'll rip the missing tunes (and the ones I edited with vgm-facc) and I'll upload the pack. If you can strip the unused samples, the VGM's will be ok!

Hope this will be usefull for other neo-geo games.

I might rip Puzzle de pon! (I also love that music!). :)

mills wrote

I might rip Puzzle de pon! (I also love that music!). :)

Go for it :O

Puzzle the pon runs in a "normal" mame 0.136. It keeps complaining about neo-geo bios "sfix.sfix". If I copy sfix.sfix to puzzledp (uncompressed) folder, MAME complains "some rom are incorrect", and the game runs.

But Puzzle de pon refuses to run in mame_vgm..

I'll keep trying

I don't get any complaints when I run it. I guess your romsets are too old. My neogeo.zip has 1233 KB.

I finally got it! Hope you like them. The two vgmz are inside the .zip

If these tunes can be optimized and/or there are missing tunes, please tell me.

I tried to convert snow bross dro's into vgm's so that I could edit and loop them but the resulting vgm's didn't play at all :(.

I ripped some snowbros vgm's using mame_vgm and they are huge!

Pbobble-Pzzledp.zip (1.17 MB)

The tunes are really nice. I like them.

I have no idea why your dro2vgm files didn't play. I converted the Snow Bros dros and it worked, but the tones are a little too high compared to MAME VGM.

And I know that the Snow Bros vgms are really huge. (I used that game to test YM3812 logging.) Just compress them with vgm_cmp and the files will be as small as the dro2vgm files.

Thanks! compressed snowbros vgm's are perfect!

I noticed neo-geo vgm's have the sample rom duplicated and a lot of "empty" gaps that make the files very big.

This is Puzzle de pon menu oppened in audacity --> import raw data --> ADPCM

I saw the same in a hex editor, the first part with that "mountains" are the samples and you can see they are duplicated, and a lot of gaps too. (This also happens with pbobble).

I played with the hex editor and replaced one of the two "sample sets" (The 2º one) with 00 00... and it works!. This does not reduce the file size ... I know I'm a noob :)

But If I delete the data, the song doesn't play at all. :)

Puzzle Bobble is done.
You can download the pack from my VGM Pack Folder.

I noticed that the ingame tune (without intro) has two different speeds, depending on the previous played tune..
Normal Speed: play tune 12, then 24
Higher Speed: play tune 25 or 26, then 24
Do you know why the ending tune has two versions? (26 with intro, 27 without intro)

My tool isn't done yet. Although my tool works well with Puzzle Bobble, some vgms of Puzzle De Pon don't work because of some oddities of the sound driver.

It's interesting that the samples are duplicated. I think that was the case with Out Run, too.
And you can delete data, but you need to search for 67 66 82 and change the four following bytes. If you only want to play around you don't need to change any other bytes. Of course it won't find the GD3 tag anymore. :)
You can also delete the block 67 66 83 ... (that should be the second copy of the sample rom) without hurting anything.

Wow! now they are really optimized! Package version should be 2.0 final! :)

I noticed the two versions of the ending tune in pbobble, may be the little intro is skipped if you push a button and the game plays the credits tune.

Hope to see your tool finished! (next step is in_vgm support.. ok I'll stop begging.. haha).

I just finished Puzzle De Pon. Download is here.
I also moved many packs I made to my vgm folder.

There's also one SegaSonic Arcade track: Trap Tower.
I know it's huge, but the RF-PCM chips are an advanced version of YM2612's DAC and don't have Sample-ROM.

I also added a new value to the vgm header: the loop modifier. (It's location is 0x7F because I didn't want to interrupt the list of chip-frequencies. See attached vgm spec)
I'll upload an updated VGMPlay soon.

I attached a description template that fits more to non-SMS games.

In the future I want to implement the sound chip of SegaCD and 32x, but I wasn't able to compile the Gens/GS source yet.

vgmspec151.txt (14.07 KB)

vgm spec 1.51 - loop modifier update

description_vgm151.txt (1.29 KB)

Description template

ValleyBell wrote

In the future I want to implement the sound chip of SegaCD and 32x, but I wasn't able to compile the Gens/GS source yet.

Looking forward to that! :)

I just notified GerbilSoft about this.

<GerbilSoft> k
<GerbilSoft> well
<GerbilSoft> stuff's still in progress
<GerbilSoft> <_<
<GerbilSoft> but right now adding VGM would be subpar
<GerbilSoft> because gens isn't very accurate for music timing
<GerbilSoft> in particular, it's only scanline accurate
<GerbilSoft> 15734 Hz maximum update frequency
<GerbilSoft> 15625 in PAL
<GerbilSoft> eventually i'll update all the ICs to run at their native frequency (it'll end up being slower, but better)

Hopefully he'll post in this thread. You two can really help eachother.

I love this forum!

I ripped a tune from Metal slug 2, it's 20 MB!, and I noticed this game has no synth sounds, everything is made using samples like a tracker (IT,XM,MOD...).

I tried to rip The simpsons arcade.

YM2151 is ripped but K053260 (ADPCM) does not work.

Edit; it works but not all times...

Could you (ValleyBell) make a tool to cut the vgm's? I mean, from one sample to another sample (not to split them in parts). This way it wolud be easier to rip (for example the simpsons) all the tunes in a big vgm and then cut them... Is difficult to do this using vgm_split.

Thanks

I'll write an alternative tool to vgm_splt.
And can't be K053260 ripped, because vgms are currently lacking the support it.

I just finished the openMSX VGM mod.
You can download the full version or a source diff file.
Supported are: YM2413 (OPLL), YM2151, YMF262, YMF278 and Y8950.
There's no support for the MSX PSG (AY8910) chip.

I wish a successful ripping.

Sega MegaCD PCM vgms are in sight ...

Getting GensGS to compile under Windows was a tough piece, but it's done. I spent many hours into compiling, reinstalling MinGW and trying again. Finally I realized that the source needs to be patched to compile successfully.
(It needed only 2 patches, but it was surprisingly enough that it wasn't my fault that prevents it from compiling.)
Also it took me an hour to insert the .c-file that logs vgms. The makefiles are so complicated. (Sorry, but the ones of MAME and openMSX were a lot clearer).

That's for now. In 2 or 3 weeks I should have a good vgm-logging GensGS.

It's great to hear that, but I still think you should really coordinate with GerbilSoft, so your additions could become part of the main Gens/GS codebase. His contact information is public on his Sonic Retro profile. I insist because I am sure you two could really help eachother.

I need to contact him either way. There are some parts of the Gens/GS code that are in asm - some parts that are important for vgm logging. And I can only read a little asm.

But at least the SegaCD PCM core is implemented in VGMPlay and working. I tested this by saving ram-shots. That's okay for testing, but nothing "good".

where can i find the latest vgmplay source?
is it very windows centric or is it crossplatform?

I don't seem to do any updates to VGMPlay during the next couple of weeks.
So I attached the lastest VGMPlay with source.

It's crossplatform and should compile with Windows and Linux.
Maybe compiling under Linux may require some (small) changes. Some time passed since I compiled it the last time on openSUSE.

VGMPlay.rar (154.5 KB)

lastest VGMPlay (windows exe)

VGMPlay_src.rar (460.26 KB)

lastest VGMPlay (source)

Thank you!!

Compiling under ubuntu gives me this error:
VGMPlay.cpp: In function ‘bool OpenPlayListFile(const char*)’:
VGMPlay.cpp:1258: error: invalid conversion from ‘const char*’ to ‘char*’
VGMPlay.cpp: In function ‘bool OpenVGMFile(const char*)’:

Changing line 1258 to this:

RetStr = strrchr((char*)FileName, DIR_CHR);

fixed it... but it seems a header is missing too.

ChipMapper.cpp:56:27: error: chips/rf5c164.h: No such file or directory
ChipMapper.cpp: In function ‘void chip_reg_write(unsigned char, unsigned char, unsigned char, unsigned char, unsigned char)’:
ChipMapper.cpp:569: error: ‘rf5c164_w’ was not declared in this scope
make: *** [obj/ChipMapper.o] Error 1

Sorry, the header file "rf5c164.h" should actually be "scd_pcm.h".
After that change, it should compile successfully.

right, now it linked under ubuntu, time to try to compile it under amigaos4.
i got this warning when linking though:
VGMPlay.cpp:(.text+0xe1): warning: the `gets' function is dangerous and should not be used.

oops. the exe crashes hard.

VGM Player
----------
*** glibc detected *** ./VGMPlay: free(): invalid next size (normal): 0x094d0038 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x251591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x252de8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x255ecd]
/lib/tls/i686/cmov/libc.so.6(+0x5c410)[0x242410]
/lib/tls/i686/cmov/libc.so.6(fopen+0x2c)[0x24244c]
./VGMPlay[0x8049dec]
./VGMPlay[0x80495eb]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x1fcbd6]
./VGMPlay[0x80494b1]
======= Memory map: ========
0012d000-00134000 r-xp 00000000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
00134000-00135000 r--p 00006000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
00135000-00136000 rw-p 00007000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
001bd000-001d8000 r-xp 00000000 08:01 263 /lib/ld-2.11.1.so
001d8000-001d9000 r--p 0001a000 08:01 263 /lib/ld-2.11.1.so
001d9000-001da000 rw-p 0001b000 08:01 263 /lib/ld-2.11.1.so
001e5000-001e6000 r-xp 00000000 00:00 0 [vdso]
001e6000-00339000 r-xp 00000000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
00339000-0033a000 ---p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
0033a000-0033c000 r--p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
0033c000-0033d000 rw-p 00155000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
0033d000-00340000 rw-p 00000000 00:00 0
003b6000-003d3000 r-xp 00000000 08:01 850 /lib/libgcc_s.so.1
003d3000-003d4000 r--p 0001c000 08:01 850 /lib/libgcc_s.so.1
003d4000-003d5000 rw-p 0001d000 08:01 850 /lib/libgcc_s.so.1
004a4000-004b9000 r-xp 00000000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
004b9000-004ba000 r--p 00014000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
004ba000-004bb000 rw-p 00015000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
004bb000-004bd000 rw-p 00000000 00:00 0
00764000-0084d000 r-xp 00000000 08:01 19 /usr/lib/libstdc++.so.6.0.13
0084d000-0084e000 ---p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13
0084e000-00852000 r--p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00852000-00853000 rw-p 000ed000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00853000-0085a000 rw-p 00000000 00:00 0
00bf1000-00c15000 r-xp 00000000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
00c15000-00c16000 r--p 00023000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
00c16000-00c17000 rw-p 00024000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
08048000-080ae000 r-xp 00000000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay
080ae000-080af000 r--p 00065000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay
080af000-080b2000 rw-p 00066000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay
080b2000-08428000 rw-p 00000000 00:00 0
094cf000-094f1000 rw-p 00000000 00:00 0 [heap]
b7700000-b7721000 rw-p 00000000 00:00 0
b7721000-b7800000 ---p 00000000 00:00 0
b783a000-b783d000 rw-p 00000000 00:00 0
b7850000-b7853000 rw-p 00000000 00:00 0
bfa42000-bfa57000 rw-p 00000000 00:00 0 [stack]
Aborted

btw, to further improve portability, could support for libao or sdl be added for sound output perhaps?

regarding gets() i found this:

gets() is deprecated and unsafe.

Use fgets() instead.

It seems that it produces that crash when it tries to load the ini-file. (Actually I'm sure about that.)
Unfortunately it works on Windows and openSUSE so I can't fix that by myself.

Please open VGMPlay.cpp and goto line 822.
Now insert a printf-line to print FileName.
You can add a return; to skip the ini-file.

And now some words to gets():
I left that in (although I got the same warning when compiling under openSUSE) because:
- I'm a little lazy
- MSVC++6 doesn't show a warning (I know that this isn't a real reason)
- fgets() includes a \n which I don't need
- the filled buffer is long enough for file names

I won't add support for other libs.
But if you want to add something you can write it by yourself. I would add it gladly to the player. (of course with given credit)

Valley Bell noticed a bad loop in Stage 2 I fixed it.

I ripped some cool tunes from a shinchan game (Crayon shin chan orato asobo)
This game uses ym2610 but vgm_trim destroys adpcm data.
I upload a Shin chan tune.

Puzzle De Pon.vgm7z (87.61 KB)

Shinchan intro-scene.vgm.zip (46.09 KB)

i am not really a coder, i am just trying to get this compiled, and forward it to a friend that is a coder.. =)
what do i need to add? my try failed. hard. haha.

I uploaded the fixed Puzzle de Pon! pack (also fixed tags and txt-file) and edited the first post. I listed all emulator-mods with download links. It took some minutes but it's nicer to have all things at the main post.

@spotUP: I added some printf-lines to the source (see attached zip). Please recompile with these files and post the messages it displays before crashing.

EDIT:
@mills: I'm working on a fix for your shinchan game. The problem is the way vgm_trim works. Unlike VGMTool I want small vgms although it means that I need to fix some things.
An example:
If you trim a YM2612 vgm with VGMTool (2), all command before the starting point will remain in the vgm (only delays are stripped). That's very safe but the vgms may be larger than they have to be.
If you do the same with vgm_trim all events before the starting point will be stripped. That makes them smaller (especially if they use DAC) but you may e.g. need to reinsert the command to enable the DAC.

I want to find a way between these extreme cases and already made some notes. I just have to code it.

VGMPlay_test.zip (29.84 KB)

INI Filename: /home/johan/Desktop/vgmplay/VGMPlay.ini
*** glibc detected *** ./VGMPlay: free(): invalid next size (normal): 0x08dec038 ***

Author	Message
ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Wed Feb 03, 2010 9:15 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	A Winamp-like wave dumper should be quite easy. I'll put that on my todo list. Playlists are planned, too.

Blargg Joined: 12 Nov 2005 Posts: 54	Posted: Mon Feb 08, 2010 10:59 pm
Blargg Joined: 12 Nov 2005 Posts: 54	Would there be any big problem with also adding a "logging rate" field to this version of the format? Normal VGM files use a rate of 44100 Hz. This would allow setting the rate, for example, to the sampling rate of the FM chip (e.g. 53267.0454545...), so that writes occur during the same FM samples as they originally did. It could be expressed as a rational value, allowing exact representations of the actual FM rate. Just an idea, anyway.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Tue Feb 09, 2010 10:03 am
	That might be a good way to bolt on "super-accurate timing" to the format. (Redoing the whole thing from scratch would be even better, there are so many mistakes in the format...) I'm mostly of the opinion that the dominant player gets to define the standard for things like this (for better or worse). If someone can come along and make a decent replacement for in_vgm I'd be happy to give it up to be honest.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Tue Feb 09, 2010 3:03 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	VGM Player with DiskWriter function http://www.mediafire.com/?jvdyuujdimd The ini-file is now well documented, so look into it. You can pause or fade (key 'F') the music even if there's no sound. In my opinion a "logging rate" should be a feature of vgm v2. Every chip has its own sample rate, so this is almost impossible with the current version. But it may be a good idea to think about vgm v2.

Blargg Joined: 12 Nov 2005 Posts: 54	Posted: Tue Feb 09, 2010 5:27 pm
Blargg Joined: 12 Nov 2005 Posts: 54	Yeah, I was just thinking of a simple approach to solve possible issues with FM writes being slightly too early or late as the current VGM timing can cause. I don't know a lot about how the FM chips work, and whether writes to them can be timing-sensitive such that a write being one FM sample earlier or later can make a large difference in the sound; I'd love to find out that it's not that sensitive. Hopefully the main problem we've been having with FM music is due merely to not running the FM chips at their proper rates. The idea was that there is probably only one FM sound chip used by a given song (or if multiple FM chips, they are of the same sample rate and synchronized), so that all the FM writes could be at the proper times without needing multiple rates. PSG writes wouldn't be exact, but the PSG isn't super-sensitive to write times. I agree that a version 2 should either allow a "sample" rate in the tens of MHz, and derive each sound chip's clock by dividing it by an integer. You could do this even with the current format, but the added entropy in the delays would probably bloat files a lot. The other approach of course is to have separate streams for each sound chip, each stream having its own clock rate (if someone can write a player with keeps each stream properly synchronized and all, not an easy task). Oh, and a small error in the VGM specs that's been nagging me: for the YM2612 clock rate field, it says "Input clock rate in Hz for the YM2612 chip. A typical value is 3579545", even though the YM2612 typically runs at a rate almost double that. The 1.51 spec seems to possibly extend this error to the new FM chips as well.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Tue Feb 09, 2010 7:59 pm
	Blargg wrote Yeah, I was just thinking of a simple approach to solve possible issues with FM writes being slightly too early or late as the current VGM timing can cause. I don't know a lot about how the FM chips work, and whether writes to them can be timing-sensitive such that a write being one FM sample earlier or later can make a large difference in the sound; I'd love to find out that it's not that sensitive. In theory, you need to be accurate to the very clock cycle of the original chip, as the combinatorial nature of the synthesis (feedback, modulation, etc) means it might be highly sensitive to these in certain cases. Specifying the master clock as an integer multiple of all the chips' clocks is one option, but as you said that makes the pause lengths larger numbers. That's an issue regardless. Blargg wrote I agree that a version 2 should either allow a "sample" rate in the tens of MHz, and derive each sound chip's clock by dividing it by an integer. I think the best approach would be to have one "sample rate" per chip stream. VGM as designed has a reasonably front-to-back ordering (no seeking and only one file pointer required for basic playback), but if we let that go out the window then there's no reason not to, for example, have one stream for the wait lengths and another for the chip writes, and save all the overhead of using a leading byte for every "command". The difficulty comes from emulator support (for them it's easiest if they can dump a header, then a byte or three for every chip write, then maybe a bit of header fixup when logging stops). So the format ought to support an interleaved stream to make that easier; conversion between the two ought to be easily testable for the support tools. Optvgm is a great example of this stream splitting and postprocessing. Blargg wrote (if someone can write a player with keeps each stream properly synchronized and all, not an easy task). I don't see that it's a great difficulty. Effectively you have multiple one-chip player mixing their outputs, they just happen to share a file on disk. Blargg wrote Oh, and a small error in the VGM specs that's been nagging me: for the YM2612 clock rate field, it says "Input clock rate in Hz for the YM2612 chip. A typical value is 3579545", even though the YM2612 typically runs at a rate almost double that. The 1.51 spec seems to possibly extend this error to the new FM chips as well. Hmm, that's quite horribly wrong :) I fixed the one at http://www.smspower.org/music/uploads/Help/vgmspec150.txt .

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Wed Feb 10, 2010 7:40 pm Last edited by ValleyBell on Thu Feb 11, 2010 8:06 am; edited 1 time in total
ValleyBell Joined: 15 Sep 2009 Posts: 378	I went through a lot of MAME's driver files and corrected some clock rates. 3579545 is good for the YM3526 and YM3812. The corrected spec. is attached. I recently looked into the Gens source code and I may or may not add the SegaCD PCM chip (RF5C164), so the current spec 1.51 is something beta-like. EDIT: Oops, I forgot to attach the file. vgmspec151.txt (13.58 KB) VGM spec 1.51 clock rate fix

Hendricks266 Joined: 10 Jul 2009 Posts: 20 Location: United States	Posted: Wed Feb 10, 2010 11:18 pm
	If you decide to implement the SCD PCM, I would recommend you use Gens/GS as a source.

Blargg Joined: 12 Nov 2005 Posts: 54	Posted: Wed Feb 24, 2010 2:32 pm
Blargg Joined: 12 Nov 2005 Posts: 54	Maxim wrote I'm mostly of the opinion that the dominant player gets to define the standard for things like this (for better or worse). If someone can come along and make a decent replacement for in_vgm I'd be happy to give it up to be honest. I think it's defined by anyone who manages to dump a lot of games in a particular format. If the dumps are better than the previous format, or are of lots of previously-undumped/undumpable games, then player authors will naturally write code to play them back.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Fri Jul 09, 2010 6:56 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I have worked on my VGM Player a lot. New features are: - a Linux port - Playlist support - Seeking Forward/Backward - for owners of a soundcard with OPL chip: FM hardware emulation (including seeking) (I have a Soundblaster 16) For more info you can read the readme file. Here's the player: http://www.mediafire.com/?y0lzdjkruz2 VGMPlay.exe is for Windows and VGMPlay for OpenSUSE. And the full source code: http://www.mediafire.com/?mxwndj32jwm It compiles with MS VC++ 6 and GNU make (tested with OpenSuse). To show the power of Hardware FM, I recorded some pieces of music. http://www.mediafire.com/?sharekey=35dd0dea0623d548aaca48175a79d1c355fec1fd8b138836a4648785df63f216 There is the Cave Theme from Phantasy Star which lets you hear the difference between Meka's OPL Mapper and my custom one. Space Harrier Theme shows two things: 1. my OPL Mapper for the PSG sound chip 2. a common bug of many early YM2413 VGMs (just listen to "New" at 0:26 and "old" at 0:06") This happens when an instrument change is sent after a note was set on, because the commands are sorted. (NoteOn: 0x20, InstrumentChange: 0x30) You may not hear a difference with any software emulator, because both messages are sent before a sample is generated. That's not the case on real hardware and playing such vgms on a real SMS can produce the same bug. OK, enough words. Have fun! EDIT: Link update because of small bugfix

mills Joined: 04 Aug 2010 Posts: 38	snow bross rip Posted: Wed Aug 04, 2010 11:44 pm
mills Joined: 04 Aug 2010 Posts: 38	Hi everybody. I love this web! I have thousands of files in my psp! ( mame vgm's doesn't work yet in Game Music Gear... ok I won't beg ) First of all, may be somebody finds this usefull: I managed to rip "snow bross" music in a strange way. The game uses ym3812 aka OPL chip (the same as sound blaster 16/adlib). I got an old mame for ms-dos (0.32). this version can use the ym3812 from the sound blaster to reproduce music. I loaded mame using Dosbox. Dosbox can rip "raw OPL data"... I got perfect rips from the game in .dro format (dosbox raw opl), you can play .dro with adplug plugin. I know this web is for the VGM but I think this could be usefull for some mame games. I upload the .dro files :) Going back to VGM's... I want to rip some vgm's from neo geo roms but they are not working with this mamevgm, :( , I don't know... I'd be happy just with puzzle bobble vgm's I love that game. If somebody gets pbobble working with mamevgm, please tell me. Forgive me for my bad English. Snow bross - Dosbox Raw OPL rip .zip (21.52 KB) Ripped with Dosbox

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Thu Aug 05, 2010 8:59 am
ValleyBell Joined: 15 Sep 2009 Posts: 378	MAME VGM should support pbobble and NeoGeo ROMs. I'm sure the version from January had YM2610 support, but I don't know. Here's a link to the lastest version of MAME VGM: http://www.mediafire.com/?8t71gtqzdhvcrsp I tested pbobble and it worked. And for Snow Bros: You can make vgms with MAME VGM. That's more accurate. (dro: 1000 Hz, vgm: 44100 Hz) And AdPlug for Winamp doesn't play these dro files (they are dro version 2). So I use my own VGM Player instead which supports dro files, too (in v0, v1 and v2). And btw: I have complete rip of Lemmings DOS in dro format on my HD. I haven't made a good dro2vgm yet, but it's coming soon.

mills Joined: 04 Aug 2010 Posts: 38	Posted: Thu Aug 05, 2010 10:33 am
mills Joined: 04 Aug 2010 Posts: 38	Well these .dro files play at 44100 Hz in GMGear (PSP), but you are right, VGM is better because .dro files are not always played very well. Mamevgm keeps complaining "no chd images" I'm missing something ??. edit: ups bad romset.. problem solved! now I'll try vgm tools to optimize the music! the intro tune is 2 MB! and I have to find if puzzle bobble has a test menu to play the music without ingame sounds :)

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Fri Aug 06, 2010 7:20 am
ValleyBell Joined: 15 Sep 2009 Posts: 378	pbobble has a test menu by pressing F2. pbobbleN doesn't. I checked that when I tested these sets. And EVERY tune has a 2 MB Sample-ROM (pbobble, it's 7 MB for pbobblen). After trimming/tagging the files you can send them to me and I'll see how to optimize the ROM data. I just noticed that vgm_trim strips the Sample-ROM. So the trimmed files are much smaller, but lack drums and speech. I'll fix that.

mills Joined: 04 Aug 2010 Posts: 38	Puzzle bobble VGM Posted: Tue Aug 10, 2010 6:10 pm Last edited by mills on Tue Aug 10, 2010 8:30 pm; edited 5 times in total
mills Joined: 04 Aug 2010 Posts: 38	I ripped all the tunes (not the short sound effects), each VGM is 2.0 - 2.2 MB. Ingame, 2 Players and continue tunes are trimmed. If the unused ADPCM data is deleted (How?) the size should be much smaller. They play very well in VGMPlay, in_vgm plugin doesn't play them at all (winamp). Edit: Thanks Tom I'm using linux and I don't use zip files, I couldn't upload a 7z (600 K). Anyway these files are not optimized... hope they will... and we won't need to compress them :) I think each tune would be 160 Kb or less without all unused samples Puzzle Bobble.rar (795.9 KB)

Tom Joined: 16 May 2002 Posts: 1378 Location: italy	Posted: Tue Aug 10, 2010 6:23 pm
Tom Joined: 16 May 2002 Posts: 1378 Location: italy	I love Puzzle Bobble, thanks for the rip! By the way, your RAR file is huge because you made a standard RAR file. Since all those songs share samples between eachother, a solid RAR file would have been much more effective. Your file is 4.72MB, once recompressed in a solid RAR file it becomes 795kB. Download it here.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Tue Aug 10, 2010 7:37 pm
	...VGM7z is designed for that sort of thing.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Tue Aug 10, 2010 9:07 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I always thought that 200 KB is too small for a VGM7z pack. The Puzzle Bobble rip sounds nice, but I noticed that the vgms were rounded to frames. This may be fine for SMS and some other consoles, but I experienced that it's very uncommon for arcade games to be frame-accurate. So I would avoid to round arcade music in general. (I think that OutRun had an accuracy of 110-120 frames or so.) I think that there are 2 tunes missing: 24 (ingame without intro) and 28. I'll use these files to write a new tool since I don't want to do that by hand too many times. Btw: When I stripped unused samples from OutRun vgms, I used my vgm player to create a mask of used data-bytes. I think some parts are still in the source code.

mills Joined: 04 Aug 2010 Posts: 38	Posted: Tue Aug 10, 2010 9:47 pm
mills Joined: 04 Aug 2010 Posts: 38	Well I used vgm facc with two of the songs, just to test and the size was a bit smaller. I used load/save state in the test menu to rip one by one, whith a little silence at the beggining. I'll rip the missing tunes (and the ones I edited with vgm-facc) and I'll upload the pack. If you can strip the unused samples, the VGM's will be ok! Hope this will be usefull for other neo-geo games. I might rip Puzzle de pon! (I also love that music!). :)

Tom Joined: 16 May 2002 Posts: 1378 Location: italy	Posted: Wed Aug 11, 2010 12:37 am
Tom Joined: 16 May 2002 Posts: 1378 Location: italy	mills wrote I might rip Puzzle de pon! (I also love that music!). :) Go for it :O

mills Joined: 04 Aug 2010 Posts: 38	Posted: Thu Aug 12, 2010 12:22 pm
mills Joined: 04 Aug 2010 Posts: 38	Puzzle the pon runs in a "normal" mame 0.136. It keeps complaining about neo-geo bios "sfix.sfix". If I copy sfix.sfix to puzzledp (uncompressed) folder, MAME complains "some rom are incorrect", and the game runs. But Puzzle de pon refuses to run in mame_vgm.. I'll keep trying

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Fri Aug 13, 2010 6:51 am
ValleyBell Joined: 15 Sep 2009 Posts: 378	I don't get any complaints when I run it. I guess your romsets are too old. My neogeo.zip has 1233 KB.

mills Joined: 04 Aug 2010 Posts: 38	[VGM pack] Puzzle bobble & Puzzle de pon Posted: Sat Aug 14, 2010 4:00 pm
mills Joined: 04 Aug 2010 Posts: 38	I finally got it! Hope you like them. The two vgmz are inside the .zip If these tunes can be optimized and/or there are missing tunes, please tell me. I tried to convert snow bross dro's into vgm's so that I could edit and loop them but the resulting vgm's didn't play at all :(. I ripped some snowbros vgm's using mame_vgm and they are huge! Pbobble-Pzzledp.zip (1.17 MB)

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Sun Aug 15, 2010 7:34 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	The tunes are really nice. I like them. I have no idea why your dro2vgm files didn't play. I converted the Snow Bros dros and it worked, but the tones are a little too high compared to MAME VGM. And I know that the Snow Bros vgms are really huge. (I used that game to test YM3812 logging.) Just compress them with vgm_cmp and the files will be as small as the dro2vgm files.

mills Joined: 04 Aug 2010 Posts: 38	Posted: Mon Aug 16, 2010 9:28 pm
mills Joined: 04 Aug 2010 Posts: 38	Thanks! compressed snowbros vgm's are perfect! I noticed neo-geo vgm's have the sample rom duplicated and a lot of "empty" gaps that make the files very big. This is Puzzle de pon menu oppened in audacity --> import raw data --> ADPCM I saw the same in a hex editor, the first part with that "mountains" are the samples and you can see they are duplicated, and a lot of gaps too. (This also happens with pbobble). I played with the hex editor and replaced one of the two "sample sets" (The 2º one) with 00 00... and it works!. This does not reduce the file size ... I know I'm a noob :) But If I delete the data, the song doesn't play at all. :)

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Mon Aug 16, 2010 10:46 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	Puzzle Bobble is done. You can download the pack from my VGM Pack Folder. I noticed that the ingame tune (without intro) has two different speeds, depending on the previous played tune.. Normal Speed: play tune 12, then 24 Higher Speed: play tune 25 or 26, then 24 Do you know why the ending tune has two versions? (26 with intro, 27 without intro) My tool isn't done yet. Although my tool works well with Puzzle Bobble, some vgms of Puzzle De Pon don't work because of some oddities of the sound driver. It's interesting that the samples are duplicated. I think that was the case with Out Run, too. And you can delete data, but you need to search for 67 66 82 and change the four following bytes. If you only want to play around you don't need to change any other bytes. Of course it won't find the GD3 tag anymore. :) You can also delete the block 67 66 83 ... (that should be the second copy of the sample rom) without hurting anything.

mills Joined: 04 Aug 2010 Posts: 38	Posted: Tue Aug 17, 2010 10:22 am
mills Joined: 04 Aug 2010 Posts: 38	Wow! now they are really optimized! Package version should be 2.0 final! :) I noticed the two versions of the ending tune in pbobble, may be the little intro is skipped if you push a button and the game plays the credits tune. Hope to see your tool finished! (next step is in_vgm support.. ok I'll stop begging.. haha).

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Thu Aug 19, 2010 9:37 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I just finished Puzzle De Pon. Download is here. I also moved many packs I made to my vgm folder. There's also one SegaSonic Arcade track: Trap Tower. I know it's huge, but the RF-PCM chips are an advanced version of YM2612's DAC and don't have Sample-ROM. I also added a new value to the vgm header: the loop modifier. (It's location is 0x7F because I didn't want to interrupt the list of chip-frequencies. See attached vgm spec) I'll upload an updated VGMPlay soon. I attached a description template that fits more to non-SMS games. In the future I want to implement the sound chip of SegaCD and 32x, but I wasn't able to compile the Gens/GS source yet. vgmspec151.txt (14.07 KB) vgm spec 1.51 - loop modifier update description_vgm151.txt (1.29 KB) Description template

Hendricks266 Joined: 10 Jul 2009 Posts: 20 Location: United States	Posted: Thu Aug 19, 2010 11:36 pm
	ValleyBell wrote In the future I want to implement the sound chip of SegaCD and 32x, but I wasn't able to compile the Gens/GS source yet. Looking forward to that! :)

Tom Joined: 16 May 2002 Posts: 1378 Location: italy	Posted: Fri Aug 20, 2010 12:23 am
Tom Joined: 16 May 2002 Posts: 1378 Location: italy	I just notified GerbilSoft about this. <GerbilSoft> k <GerbilSoft> well <GerbilSoft> stuff's still in progress <GerbilSoft> <_< <GerbilSoft> but right now adding VGM would be subpar <GerbilSoft> because gens isn't very accurate for music timing <GerbilSoft> in particular, it's only scanline accurate <GerbilSoft> 15734 Hz maximum update frequency <GerbilSoft> 15625 in PAL <GerbilSoft> eventually i'll update all the ICs to run at their native frequency (it'll end up being slower, but better) Hopefully he'll post in this thread. You two can really help eachother.

mills Joined: 04 Aug 2010 Posts: 38	Posted: Fri Aug 20, 2010 9:32 pm
mills Joined: 04 Aug 2010 Posts: 38	I love this forum! I ripped a tune from Metal slug 2, it's 20 MB!, and I noticed this game has no synth sounds, everything is made using samples like a tracker (IT,XM,MOD...).

mills Joined: 04 Aug 2010 Posts: 38	Posted: Thu Aug 26, 2010 4:53 pm
mills Joined: 04 Aug 2010 Posts: 38	I tried to rip The simpsons arcade. YM2151 is ripped but K053260 (ADPCM) does not work. Edit; it works but not all times... Could you (ValleyBell) make a tool to cut the vgm's? I mean, from one sample to another sample (not to split them in parts). This way it wolud be easier to rip (for example the simpsons) all the tunes in a big vgm and then cut them... Is difficult to do this using vgm_split. Thanks

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Sun Aug 29, 2010 1:19 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I'll write an alternative tool to vgm_splt. And can't be K053260 ripped, because vgms are currently lacking the support it. I just finished the openMSX VGM mod. You can download the full version or a source diff file. Supported are: YM2413 (OPLL), YM2151, YMF262, YMF278 and Y8950. There's no support for the MSX PSG (AY8910) chip. I wish a successful ripping.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Wed Sep 01, 2010 5:13 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	Sega MegaCD PCM vgms are in sight ... Getting GensGS to compile under Windows was a tough piece, but it's done. I spent many hours into compiling, reinstalling MinGW and trying again. Finally I realized that the source needs to be patched to compile successfully. (It needed only 2 patches, but it was surprisingly enough that it wasn't my fault that prevents it from compiling.) Also it took me an hour to insert the .c-file that logs vgms. The makefiles are so complicated. (Sorry, but the ones of MAME and openMSX were a lot clearer). That's for now. In 2 or 3 weeks I should have a good vgm-logging GensGS.

Tom Joined: 16 May 2002 Posts: 1378 Location: italy	Posted: Wed Sep 01, 2010 6:17 pm
Tom Joined: 16 May 2002 Posts: 1378 Location: italy	It's great to hear that, but I still think you should really coordinate with GerbilSoft, so your additions could become part of the main Gens/GS codebase. His contact information is public on his Sonic Retro profile. I insist because I am sure you two could really help eachother.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Thu Sep 02, 2010 7:49 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I need to contact him either way. There are some parts of the Gens/GS code that are in asm - some parts that are important for vgm logging. And I can only read a little asm. But at least the SegaCD PCM core is implemented in VGMPlay and working. I tested this by saving ram-shots. That's okay for testing, but nothing "good".

spotUP Joined: 08 Sep 2010 Posts: 8	Posted: Wed Sep 08, 2010 6:38 am
spotUP Joined: 08 Sep 2010 Posts: 8	where can i find the latest vgmplay source? is it very windows centric or is it crossplatform?

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Wed Sep 08, 2010 2:52 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I don't seem to do any updates to VGMPlay during the next couple of weeks. So I attached the lastest VGMPlay with source. It's crossplatform and should compile with Windows and Linux. Maybe compiling under Linux may require some (small) changes. Some time passed since I compiled it the last time on openSUSE. VGMPlay.rar (154.5 KB) lastest VGMPlay (windows exe) VGMPlay_src.rar (460.26 KB) lastest VGMPlay (source)

spotUP Joined: 08 Sep 2010 Posts: 8	Posted: Wed Sep 08, 2010 9:07 pm
spotUP Joined: 08 Sep 2010 Posts: 8	Thank you!! Compiling under ubuntu gives me this error: VGMPlay.cpp: In function ‘bool OpenPlayListFile(const char)’: VGMPlay.cpp:1258: error: invalid conversion from ‘const char’ to ‘char’ VGMPlay.cpp: In function ‘bool OpenVGMFile(const char)’:

spotUP Joined: 08 Sep 2010 Posts: 8	Posted: Wed Sep 08, 2010 9:43 pm
spotUP Joined: 08 Sep 2010 Posts: 8	Changing line 1258 to this: RetStr = strrchr((char)FileName, DIR_CHR); fixed it... but it seems a header is missing too. ChipMapper.cpp:56:27: error: chips/rf5c164.h: No such file or directory ChipMapper.cpp: In function ‘void chip_reg_write(unsigned char, unsigned char, unsigned char, unsigned char, unsigned char)’: ChipMapper.cpp:569: error: ‘rf5c164_w’ was not declared in this scope make: ** [obj/ChipMapper.o] Error 1

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Thu Sep 09, 2010 7:39 am
ValleyBell Joined: 15 Sep 2009 Posts: 378	Sorry, the header file "rf5c164.h" should actually be "scd_pcm.h". After that change, it should compile successfully.

spot Guest	Posted: Thu Sep 09, 2010 10:20 am
spot Guest	right, now it linked under ubuntu, time to try to compile it under amigaos4. i got this warning when linking though: VGMPlay.cpp:(.text+0xe1): warning: the `gets' function is dangerous and should not be used.

spot Guest	Posted: Thu Sep 09, 2010 10:23 am
spot Guest	oops. the exe crashes hard. VGM Player ---------- * glibc detected * ./VGMPlay: free(): invalid next size (normal): 0x094d0038 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x251591] /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x252de8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x255ecd] /lib/tls/i686/cmov/libc.so.6(+0x5c410)[0x242410] /lib/tls/i686/cmov/libc.so.6(fopen+0x2c)[0x24244c] ./VGMPlay[0x8049dec] ./VGMPlay[0x80495eb] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x1fcbd6] ./VGMPlay[0x80494b1] ======= Memory map: ======== 0012d000-00134000 r-xp 00000000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so 00134000-00135000 r--p 00006000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so 00135000-00136000 rw-p 00007000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so 001bd000-001d8000 r-xp 00000000 08:01 263 /lib/ld-2.11.1.so 001d8000-001d9000 r--p 0001a000 08:01 263 /lib/ld-2.11.1.so 001d9000-001da000 rw-p 0001b000 08:01 263 /lib/ld-2.11.1.so 001e5000-001e6000 r-xp 00000000 00:00 0 [vdso] 001e6000-00339000 r-xp 00000000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so 00339000-0033a000 ---p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so 0033a000-0033c000 r--p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so 0033c000-0033d000 rw-p 00155000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so 0033d000-00340000 rw-p 00000000 00:00 0 003b6000-003d3000 r-xp 00000000 08:01 850 /lib/libgcc_s.so.1 003d3000-003d4000 r--p 0001c000 08:01 850 /lib/libgcc_s.so.1 003d4000-003d5000 rw-p 0001d000 08:01 850 /lib/libgcc_s.so.1 004a4000-004b9000 r-xp 00000000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so 004b9000-004ba000 r--p 00014000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so 004ba000-004bb000 rw-p 00015000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so 004bb000-004bd000 rw-p 00000000 00:00 0 00764000-0084d000 r-xp 00000000 08:01 19 /usr/lib/libstdc++.so.6.0.13 0084d000-0084e000 ---p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13 0084e000-00852000 r--p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13 00852000-00853000 rw-p 000ed000 08:01 19 /usr/lib/libstdc++.so.6.0.13 00853000-0085a000 rw-p 00000000 00:00 0 00bf1000-00c15000 r-xp 00000000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so 00c15000-00c16000 r--p 00023000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so 00c16000-00c17000 rw-p 00024000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so 08048000-080ae000 r-xp 00000000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay 080ae000-080af000 r--p 00065000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay 080af000-080b2000 rw-p 00066000 08:01 1185654 /home/johan/Desktop/vgmplay/VGMPlay 080b2000-08428000 rw-p 00000000 00:00 0 094cf000-094f1000 rw-p 00000000 00:00 0 [heap] b7700000-b7721000 rw-p 00000000 00:00 0 b7721000-b7800000 ---p 00000000 00:00 0 b783a000-b783d000 rw-p 00000000 00:00 0 b7850000-b7853000 rw-p 00000000 00:00 0 bfa42000-bfa57000 rw-p 00000000 00:00 0 [stack] Aborted

spot Guest	Posted: Thu Sep 09, 2010 10:26 am
spot Guest	btw, to further improve portability, could support for libao or sdl be added for sound output perhaps?

spotUP Joined: 08 Sep 2010 Posts: 8	Posted: Thu Sep 09, 2010 10:29 am
spotUP Joined: 08 Sep 2010 Posts: 8	regarding gets() i found this: gets() is deprecated and unsafe. Use fgets() instead.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Thu Sep 09, 2010 6:03 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	It seems that it produces that crash when it tries to load the ini-file. (Actually I'm sure about that.) Unfortunately it works on Windows and openSUSE so I can't fix that by myself. Please open VGMPlay.cpp and goto line 822. Now insert a printf-line to print FileName. You can add a return; to skip the ini-file. And now some words to gets(): I left that in (although I got the same warning when compiling under openSUSE) because: - I'm a little lazy - MSVC++6 doesn't show a warning (I know that this isn't a real reason) - fgets() includes a \n which I don't need - the filled buffer is long enough for file names I won't add support for other libs. But if you want to add something you can write it by yourself. I would add it gladly to the player. (of course with given credit)

mills Joined: 04 Aug 2010 Posts: 38	Fixed Puzzle de Pon! Vgmz pack Posted: Thu Sep 09, 2010 6:21 pm
mills Joined: 04 Aug 2010 Posts: 38	Valley Bell noticed a bad loop in Stage 2 I fixed it. I ripped some cool tunes from a shinchan game (Crayon shin chan orato asobo) This game uses ym2610 but vgm_trim destroys adpcm data. I upload a Shin chan tune. Puzzle De Pon.vgm7z (87.61 KB) Shinchan intro-scene.vgm.zip (46.09 KB)

spot Guest	Posted: Fri Sep 10, 2010 6:05 am
spot Guest	i am not really a coder, i am just trying to get this compiled, and forward it to a friend that is a coder.. =) what do i need to add? my try failed. hard. haha.

ValleyBell Joined: 15 Sep 2009 Posts: 378	Posted: Fri Sep 10, 2010 5:47 pm
ValleyBell Joined: 15 Sep 2009 Posts: 378	I uploaded the fixed Puzzle de Pon! pack (also fixed tags and txt-file) and edited the first post. I listed all emulator-mods with download links. It took some minutes but it's nicer to have all things at the main post. @spotUP: I added some printf-lines to the source (see attached zip). Please recompile with these files and post the messages it displays before crashing. EDIT: @mills: I'm working on a fix for your shinchan game. The problem is the way vgm_trim works. Unlike VGMTool I want small vgms although it means that I need to fix some things. An example: If you trim a YM2612 vgm with VGMTool (2), all command before the starting point will remain in the vgm (only delays are stripped). That's very safe but the vgms may be larger than they have to be. If you do the same with vgm_trim all events before the starting point will be stripped. That makes them smaller (especially if they use DAC) but you may e.g. need to reinsert the command to enable the DAC. I want to find a way between these extreme cases and already made some notes. I just have to code it. VGMPlay_test.zip (29.84 KB)

spot Guest	Posted: Sat Sep 11, 2010 12:48 pm
spot Guest	INI Filename: /home/johan/Desktop/vgmplay/VGMPlay.ini * glibc detected * ./VGMPlay: free(): invalid next size (normal): 0x08dec038 ***

Forums

View topic - VGM Logging with other Emulators