Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - VGM Logging with other Emulators

Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Sat Sep 11, 2010 2:07 pm
Hmm ... Just as I thought. I have absolutely no idea why fopen causes a crash.

Try that:
- open VGMPlay.cpp
- goto line 822 - it should be printf("INI Filename: %s\n", FileName);
- insert a new line below: return;
- compile again

It should then ask you for a vgm file and the rest should be fine.
  View user's profile Send private message Visit poster's website
spot
  • Guest
Reply with quote
Post Posted: Sat Sep 11, 2010 8:06 pm
VGM Player
----------
INI Filename: /home/johan/Desktop/vgmplay/VGMPlay.ini

File Name:
 
spot
  • Guest
Reply with quote
Post Posted: Sat Sep 11, 2010 8:09 pm
File Name: Dragon Crystal (GG) - 01 - Title Screen.vgm
*** glibc detected *** ./VGMPlay: free(): invalid next size (normal): 0x087dc038 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x4ea591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x4ebde8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x4eeecd]
/lib/tls/i686/cmov/libc.so.6(fclose+0x14a)[0x4daaaa]
./VGMPlay[0x804a17c]
./VGMPlay[0x804a192]
./VGMPlay[0x804962c]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x495bd6]
./VGMPlay[0x8049411]
======= Memory map: ========
00110000-0012d000 r-xp 00000000 08:01 850 /lib/libgcc_s.so.1
0012d000-0012e000 r--p 0001c000 08:01 850 /lib/libgcc_s.so.1
0012e000-0012f000 rw-p 0001d000 08:01 850 /lib/libgcc_s.so.1
0038a000-00391000 r-xp 00000000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
00391000-00392000 r--p 00006000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
00392000-00393000 rw-p 00007000 08:01 270894 /lib/tls/i686/cmov/librt-2.11.1.so
0040f000-00424000 r-xp 00000000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
00424000-00425000 r--p 00014000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
00425000-00426000 rw-p 00015000 08:01 270892 /lib/tls/i686/cmov/libpthread-2.11.1.so
00426000-00428000 rw-p 00000000 00:00 0
0047f000-005d2000 r-xp 00000000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
005d2000-005d3000 ---p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
005d3000-005d5000 r--p 00153000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
005d5000-005d6000 rw-p 00155000 08:01 265102 /lib/tls/i686/cmov/libc-2.11.1.so
005d6000-005d9000 rw-p 00000000 00:00 0
006f1000-0070c000 r-xp 00000000 08:01 263 /lib/ld-2.11.1.so
0070c000-0070d000 r--p 0001a000 08:01 263 /lib/ld-2.11.1.so
0070d000-0070e000 rw-p 0001b000 08:01 263 /lib/ld-2.11.1.so
00b50000-00b74000 r-xp 00000000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
00b74000-00b75000 r--p 00023000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
00b75000-00b76000 rw-p 00024000 08:01 270882 /lib/tls/i686/cmov/libm-2.11.1.so
00bac000-00c95000 r-xp 00000000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00c95000-00c96000 ---p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00c96000-00c9a000 r--p 000e9000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00c9a000-00c9b000 rw-p 000ed000 08:01 19 /usr/lib/libstdc++.so.6.0.13
00c9b000-00ca2000 rw-p 00000000 00:00 0
00e14000-00e15000 r-xp 00000000 00:00 0 [vdso]
08048000-080ad000 r-xp 00000000 08:01 1179932 /home/johan/Desktop/vgmplay/VGMPlay
080ad000-080ae000 r--p 00064000 08:01 1179932 /home/johan/Desktop/vgmplay/VGMPlay
080ae000-080b1000 rw-p 00065000 08:01 1179932 /home/johan/Desktop/vgmplay/VGMPlay
080b1000-08427000 rw-p 00000000 00:00 0
087db000-087fd000 rw-p 00000000 00:00 0 [heap]
b7700000-b7721000 rw-p 00000000 00:00 0
b7721000-b7800000 ---p 00000000 00:00 0
b78db000-b78de000 rw-p 00000000 00:00 0
b78f0000-b78f4000 rw-p 00000000 00:00 0
bfe33000-bfe48000 rw-p 00000000 00:00 0 [stack]
Aborted
johan@ubuntu-laptop:~/Desktop/vgmplay$
 
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Sun Sep 12, 2010 7:58 am
I'm very sorry, but I give up. I would need to test it by myself to find the exact error.
But it seems to me like a bug of the compiler because it works with Windows and openSUSE.

If someone finds a solution I'd be very grateful.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Easy way rip Neo Geo Music
Post Posted: Wed Sep 22, 2010 10:34 am
Neo Geo Unibios 2.2 - 2.3 ... has a jukebox in it



The problem is, I don't Know how to configure MAME_VGM to use this Bios (is nside negogeo.zip) By default MAME uses the first Bios (The old one).
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Sep 22, 2010 11:46 am
It took me some time to find the option, but it's easy to change the bios.

Just open mame.ini and search for "bios" (gruop CORE MISC OPTIONS).
Then insert the name of the bios ("uni-bios_2_3" should be what you want).
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Post Posted: Wed Sep 22, 2010 11:50 am
Thanks!

Much easier now to rip a lot of tunes!

Wow! With this bios jukebox I discovered some secret tunes in Puzzle de pon!

It's time to rip! :)
  View user's profile Send private message
  • Joined: 16 May 2002
  • Posts: 1355
  • Location: italy
Reply with quote
Post Posted: Wed Sep 22, 2010 1:55 pm
mills wrote
Wow! With this bios jukebox I discovered some secret tunes in Puzzle de pon!
Does it follow the M1 numbering? Because if it's so, I can identify all these tracks:
33 demo mode
34 1P/VS mode select
35 level 1
36 level 2
37 level 3
38 VS mode
39 last level
40 continue countdown
41 game over
42 staff roll
43 collected sign
44 Visco logo
45 time over / line over
46 VS win
47 level complete
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Sep 22, 2010 4:55 pm
It uses the numbers of M1. It shows 0x07xx where xx is the number of M1 in hex.
I would like to tag the ripped/trimmed files. (I love to include sound numbers.)
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Post Posted: Wed Sep 22, 2010 5:38 pm
It follows the same order, The Vgm pack I ripped, has Vs win and VS mode missing, and another Game over sound.
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Mon Sep 27, 2010 4:29 pm
I've finished Sega MegaCD PCM logging (32x PWM is 80%). See this Sonic Retro topic for more info, the lastest VGMPlay and my OptVgmRF-tool.
I increased the vgm spec. version to 1.60 because I introduced the new command 0x68.
vgmspec160.txt (16.12 KB)
VGM Spec. 1.60

  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
M1
Post Posted: Tue Sep 28, 2010 8:03 pm
Last edited by ValleyBell on Sat Oct 30, 2010 9:20 am; edited 1 time in total
It was my "project of the day" - M1 with vgm output.
But it doesn't only write vgms (see readme), it is the most recent version of M1 you can find for Windows. (The last M1 build was Mac only.)
I compiled the M1-Mac source which contained makefiles for Windows. Nevertheless I had to rewrite 50% of my vgm-logging c-file.

Btw: Actually it's really funny to use a player to log music into a format that is played by another player.

Please note that I still recommend MAME if there's a sound test. Just for example: Deroon DeroDero lacks the YMZ-sounds in M1. (I noticed that the YMZ-chip doesn't receive any commands.)
Also every song gets its own file which can cause bugs.

EDIT: Link moved to first page, fixed the YMZ-bug
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Post Posted: Wed Sep 29, 2010 5:09 pm
Cool! I tested some games :)

I ripped another Neo Geo game using DELTA T, it's called Captain Tomaday, here's the first stage music (it has a little click, also present when you play the game). Well this song is just a stream pcm but anyway it sounds very good to be just 250 Kb.

Updated Puzzle de pon! with the VS mode music.

I also created a Vgm7z pack with the two versions I found of Neo-Geo Bios intro.

:)

Edit: I want to test some ymf262 (OPL3) musics... I tried ripping .dro files in dosbox emulating a OPL3, but this .dro files have no stereo.

How can I rip stereo vgm's from OPL3 sources?
Puzzle De Pon.Vgm7z (92.26 KB)

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Sep 29, 2010 10:16 pm
Captain Tomaday is an interesting game. The music is cool, too.

Could you please strip off the silence at the beginning of your tracks? It's easy:
- write a vgm2txt and open the txt
- goto the point where the track starts (usually a lot of commands that have neither 0x00 nor 0x7F as data value)
- search for the last longer delay (>= 1000 samples)

You can also do that with already looped vgms:
Example for Captain Tomaday tune:
- Start Sample: 33537
- Loop Sample: -2 (i.e. kepp existing loop point)
- End Sample: -1 (i.e. until the very end)

I'll upload and fix the Puzzle De Pon and NeoGeo BIOS packs.


You want to log DOS games right?
I checked some dro-logs and found the bug.
When you play these dro-files with VGMPlay, it shows "Used chips: 2x YM3812" right? Actually it should show YMF262. (OPL2 doesn't support stereo)

To fix that, you need to open the dro-files with a hex-editor. Go to offset 0x14. There should be a 01. Change it to 02 and it'll work.
I attached 2 dros (original and fixed). You can hear the difference at 0:22.
S3K_Sandopolis1.zip (26.6 KB)
S3K Sandopolis Act 1 DROs

  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Post Posted: Sun Oct 03, 2010 4:39 pm
Thanks for the .dro tip.

I was going to ask you about the big silences at the beginning :). I'm a noob.. I didn't understand very well what to do, :(
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Tue Oct 05, 2010 6:35 pm
Give me a week and I'll post some text-with-pics to explain that a little more in detail. (Sorry but currently I'm short of free time.)
Until then you can continue ripping and trimming, but don't use vgm_cmp on the files. (That's because you have to use vgm_trim again to strip the silence.)

Btw: I didn't know about the dro bug before that. I'll update dro2vgm to check/fix that.

Something off-topic:
I attached my FM Midi Player (written in January 2010). It also supports mid, cmf and laa (I like Monkey Island). It also supports the most important GM-Controllers and SysEx-Messages and has a Windows-FM-Mode (see ini-file).
The archive includes some midi-files: 2 from S3K-collection (btw: they force WinFM Mode), 1 from VGMusic.com and 1 from MI2 (S is SoftStop).
Bugs: There're sometimes problems when you seek backwards.
Maybe I'll implement vgm-logging ... ;)

Have fun!
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Sun Oct 17, 2010 12:17 pm
I've recently implemented partial VGM player support into RetroCopy (only the SMS/GG/MEGADRIVE chips) and this is the first time I've looked at the format.

I don't like the fact writes aren't cycle accurate so would be interested in working toward a new VGM standard. Having read some of Maxims posts I don't think the existing format needs to change that much, having something easy to support is a good thing when it comes to a file format.

Seeking for instance might have to process the whole file but these files are relatively small, and for todays CPUs they easily go through the whole thing multiple times per second. Since you need "state" information I can't see how else you can do it unless you seed keyframes throughout the data.

RetroCopy runs every sound chip at the native speed, ie PSG at 3.57MHz , YM2612 at 7.67MHz, etc, so I'd like the writes in new format to be cycle accurate. This also means that the timing of the CPUs in the logger program become quite important (as they affect when the sound chip itself gets the command).

My initial thoughts would be something like :-

1) Fixed size initial header.
2) 62bit timestamp table, 2 bits for chip select.
3) Writes for each chip kept separately, with commands that allow movement of a "pointer" so the same music data can be saved once.

The problem with implementing optimizations is it makes it harder to write a logger. I guess if you had a "player" that could "optimize" simple dump files from an emulator you solve that problem.
  View user's profile Send private message Visit poster's website
  • Joined: 27 May 2008
  • Posts: 161
Reply with quote
Post Posted: Thu Oct 21, 2010 7:45 am
The question is, can your brain detect the jitter, given that your listening equipment probably will introduce some of its own? I know that audiophiles will recommend jitter levels waaaaay below what could occur in VGM, but that's a different story. Have you done any recordings from your emulator of VGM playback compared to the same song when you run the actual ROM? Were there any noticeable differences?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14691
  • Location: London
Reply with quote
Post Posted: Thu Oct 21, 2010 9:13 am
The interaction between operators in a chip synth can be somewhat chaotic - in that small changes in the inputs produce large changes in the outputs. This seems more often the case for YM2612 than SN76489 and YM2413.

Regarding a format change, this would be a total compatibility break so it would be a bit of a problem. I'd love to have a new format (to be honest, the VGM 1.x format has a lot of issues) but I don't have the time to produce the "standard" player these days, emulator authors aren't going to fall over themselves to catch up with it since VGM "works", so it's going to be hard to get traction. But by all means go for it; I suggest getting a new name, though, to avoid confusion.
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Sat Oct 23, 2010 6:12 am
I guess there is very little demand for a cycle accurate player so I'll put it on hold for now. I'll likely make a "retroamp" player using the RetroCopy code so people have a platform independent player for this new format.

On VGM issues, the emulator used to write the VGM files is rather important in regards to any issues with the sound, most especially with Mega Drive as "old" emulators may have significant issues with Z80/68K timing. This would present itself most notably in games which use both CPUs to update the sound.
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Sat Oct 23, 2010 6:19 am
mic_ wrote
The question is, can your brain detect the jitter, given that your listening equipment probably will introduce some of its own? I know that audiophiles will recommend jitter levels waaaaay below what could occur in VGM, but that's a different story. Have you done any recordings from your emulator of VGM playback compared to the same song when you run the actual ROM? Were there any noticeable differences?


Initial testing would suggest there are noticeable differences in some games, though if RetroCopy wrote the VGM files I don't know if there would be the same noticeable differences. Since many of these VGM files are relying upon other emulators timing it's highly likely there will be quite a few differences.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Jul 2009
  • Posts: 20
  • Location: United States
Reply with quote
Post Posted: Sat Oct 23, 2010 5:10 pm
Would such a change in the format require redumping every VGM ever logged, or could existing ones be converted?
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Sun Oct 24, 2010 4:28 am
Hendricks266 wrote
Would such a change in the format require redumping every VGM ever logged, or could existing ones be converted?


Yes, if you want to have the increased accuracy. Basically any time an emulator improves its timing accuracy all previous files should be redone. Of course once you're at the cycle level, or very close to it, any improvement isn't likely going to bring major or audible enhancement. There are a few cases on Mega Drive, whereby if your timing is off a few cycles it could end up being a much longer sound delay than merely a few cycles

ie Imagine a scenario where the 68000 bus holds the Z80, if you miss a Z80 write to sound before this happens because your timing is one cycle off then you're going to get some weird noises. This could be part of the reason why some games have issues in VGM format, depending upon the emulator used to write them, the version used, whether it had bugs, etc. The fact that VGM takes writes and shuffles them into a 1/44100 accuracy would just compound these issues with new issues.

But basically at cycle accuracy, if the sound is fine in the emulator it will be fine in the format, there will be zero difference between the two. You can't improve beyond cycle accuracy, so the new format will basically be the last one needed from an accuracy point of view.
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Sun Oct 24, 2010 7:21 pm
Cycle accurate VGMs are actually a nice idea. It may be useful for MegaDrive games because of the DAC.
But I personally have the opinion that 44100 Hz are accurate enough for 90% of all games. Most games are scanline-accurate (2-3 vgm-samples) or even frame-accurate.
The sound chips themselves are busy after every write. (e.g. the OPL2-chip has a delay of 26 us for every reg+data-write - that's 1.15 samples of a vgm)

Most problems come from a lack of emulation. Increased accuracy can't solve that. (Although I admit that accuracy of vgms is a little low for DAC samples.)
Nevertheless it's a good idea to try what a high accuracy can do.

@RetroRalph: Please don't say that vgms "shuffle" writes. Their order remains unchanged during trimming/optvgm. (Optimizing them with VGMTool shuffles them, but that only works with PSG and YM2413.)
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Mon Oct 25, 2010 3:29 am
ValleyBell wrote
Cycle accurate VGMs are actually a nice idea. It may be useful for MegaDrive games because of the DAC.
But I personally have the opinion that 44100 Hz are accurate enough for 90% of all games. Most games are scanline-accurate (2-3 vgm-samples) or even frame-accurate.
The sound chips themselves are busy after every write. (e.g. the OPL2-chip has a delay of 26 us for every reg+data-write - that's 1.15 samples of a vgm)

Most problems come from a lack of emulation. Increased accuracy can't solve that. (Although I admit that accuracy of vgms is a little low for DAC samples.)
Nevertheless it's a good idea to try what a high accuracy can do.


I don't understand the philosophy of "well 90% is fine with X so not really important to change to Y".

At some point in the future someone will go "we need cycle accurate logger" then people will redo all games. There is no doubting this as there are no technical reasons for not doing it, anything other than the best will always be facing replacement when it comes to things like this.

ValleyBell wrote
@RetroRalph: Please don't say that vgms "shuffle" writes. Their order remains unchanged during trimming/optvgm. (Optimizing them with VGMTool shuffles them, but that only works with PSG and YM2413.)


I didn't mean the writes are rearranged, merely shuffled to a non exact spot in the timeline of when they occurred. Maybe shuffled isn't the best word to use there.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Post Posted: Mon Oct 25, 2010 6:28 pm
I think VGM's are OK the way they are. If you change something, everybody will have to dump every game again ...

I've listened a lor of vgm's from many different chips, and I have to say the sound is very good, and VGM's can store logs from many different chips. from SMS to NEO-GEO, the logs made with Valleybell's emulator are nearly perfect.

Of course the sound is not going to be perfect because you are emulating the chips, for example, OPL2/OPL3 amulators are ussually a bit poor, but VGMplayer is the best OPL2/3 emulator I listened, in my opinion, Much better than adplug.

I think the problem is emulation.
  View user's profile Send private message
  • Joined: 16 May 2002
  • Posts: 1355
  • Location: italy
Reply with quote
Post Posted: Mon Oct 25, 2010 10:19 pm
mills wrote
I think VGM's are OK the way they are.
I have to agree.

However by now I know RetroRalph will proceed on his own way, and he will introduce a new format like he did with .game even though we all were fine with .sms/.gg, so won't be surprised.
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Tue Oct 26, 2010 2:11 am
VGMs are OK! Don't get me wrong. And RetroCopy already supports playing them, so backwards compatibility is already there.

As to people redoing them, well that's part and parcel of improvement. You have people around the world redumping games just to check if they are valid, I'm sure having to do a "Final" cycle accurate dump of music from chips isn't going to be that big a problem for those interested in it. You could also easily convert all existing VGM to RGM with no loss in quality, just no gain either. So when it comes to redoing them project2612 or whatever could easily adopt a new and better format if they wanted.
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Oct 27, 2010 1:37 pm
Quote
21 Oct 2010
MAME 0.140 has been released. Enjoy!

And just 6 days later there's the release of MAME 0.140 VGM.
You can get binaries for Win32 and Win64 and a diff-file with my source-updates here.

Actually I wanted to prepare for MAME's 0.140 release, but suddenly it was there - and I hadn't done anything.

And it's not just an update of MAME. I've implemented a new chip: the AY8910. (It's the last chip for vgm version 1.51.)
I'll update openMSX to support it (more or less) soon.

Enjoy ripping!
  View user's profile Send private message Visit poster's website
  • Joined: 04 Aug 2010
  • Posts: 38
Reply with quote
Ginga Ninkyouden
Post Posted: Sun Oct 31, 2010 6:31 pm
Thanks to ValleyBell I discovered a cool game called Ginga Ninkyouden.
It's a strange arcade 16/8 bit, a beat-them-up from 1987.
It has cool music (Y8950) , (but it has also horrible tracks!), I upload two cool songs because I think the volume is a bit low, is it possible to increase the volume?.

Wen I finish it, I'll create a new topic with the music pack.

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Mon Nov 01, 2010 1:17 pm
You're right, the volume is quite low. I'll increase it before uploading the pack to Mediafire.
I attached a list file for M1. Extract the zip to M1\lists\en\ and M1 will write the title tag.
ginganin_M1lst.zip (1.02 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Thu Nov 11, 2010 7:05 pm
In the last weeks I worked a lot on VGMPlay. Here is a list of improvements:
- implemented the most recent SN76496 core from MAME (and fixed it)
- fixed the YMZ280B core (fixes can be disabled via ini-file but that sounds terrible)
- increased the accuracy of MAME's OPN-cores
- added the YM2612 core from Game Music Emu (I still prefer the newer MAME core)
- added channel muting (90% finished - muting-commands for OPL-Drums don't work, but it works via channel mask)
- added an option to set seperate fading times for playlists (fluid transitions are now possible)
- added an option to fade unedited emulator-logs

As you can see I did quite a lot. You can download VGMPlay here. I'll upload the source when I finished the muting-part.

Also I uploaded MESS 0.140 VGM. Download is here.

Finally, I want to quote some lines of MAME's SN76496 core that made me feel that MAME devs make bugs on purpose.
Quote
if (R->Register[r] != 0) R->Period[c] = R->Register[r];
else R->Period[c] = 0x400;

(quoted from MAME/src/emu/sound/sn76496.c lines 204/205 - that's where the channel's frequency is set, but I'm sure most people already know that)
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Dec 01, 2010 5:40 pm
Recently I've done some updates.
The first one is openMSX. I added the AY8910 and did some minor changes (mainly source cleanups).
The second update is MAME which now logs the YMF271 chip correctly. This chip was the last untested one. Now all chips work and all tests are finished.
I'll make a pack that uses the YMF271 chip in one of the next weeks.

You can find the links at the first post of this topic.
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Thu Dec 30, 2010 2:52 pm
I updated VGMPlay (and the source).
Channel muting works now. But there weren't any "special" updates.

You find it (as usual) at the first post.

Note: The source compiled successfully with openSUSE 11.2 (32-bit) and Ubuntu 10.10 (64-bit).
Unfortunately it failed to open the ini-file (vgms work for some reason) and the sound-device under Ubuntu. Can someone help me with that?
  View user's profile Send private message Visit poster's website
SmartOne
  • Guest
Reply with quote
Post Posted: Mon Jan 03, 2011 2:27 am
The VGM input plugin plays the DAC at the wrong pitch compared to Kega Fusion. Probably a sample rate issue. I'm using 44100 Hz.
 
SmartOne
  • Guest
Reply with quote
Post Posted: Mon Jan 03, 2011 3:08 am
You may want to reduce the overall output volume (be more like Fusion). Castlevania Bloodines "All Clear" clips in a few spots, for example.
 
  • Joined: 08 Sep 2010
  • Posts: 8
Reply with quote
Post Posted: Tue Jan 04, 2011 2:43 am
i just tried to compile the latest version under ubuntu and got:

obj/VGMPlay.o: In function `main':
VGMPlay.c:(.text+0xe3): warning: the `gets' function is dangerous and should not be used.
johan@ubuntu-laptop:~/Desktop/vgmplay$ ./VGMPlay
VGM Player
----------
*** glibc detected *** ./VGMPlay: free(): invalid next size (normal): 0x09cfb038 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x673591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x674de8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x677ecd]
/lib/tls/i686/cmov/libc.so.6(+0x5c410)[0x664410]
/lib/tls/i686/cmov/libc.so.6(fopen+0x2c)[0x66444c]
./VGMPlay[0x8049ce3]
./VGMPlay[0x80493ac]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x61ebd6]
./VGMPlay[0x8049271]
======= Memory map: ========
00549000-00566000 r-xp 00000000 08:01 850 /lib/libgcc_s.so.1
00566000-00567000 r--p 0001c000 08:01 850 /lib/libgcc_s.so.1
00567000-00568000 rw-p 0001d000 08:01 850 /lib/libgcc_s.so.1
00608000-0075b000 r-xp 00000000 08:01 266013 /lib/tls/i686/cmov/libc-2.11.1.so
0075b000-0075c000 ---p 00153000 08:01 266013 /lib/tls/i686/cmov/libc-2.11.1.so
0075c000-0075e000 r--p 00153000 08:01 266013 /lib/tls/i686/cmov/libc-2.11.1.so
0075e000-0075f000 rw-p 00155000 08:01 266013 /lib/tls/i686/cmov/libc-2.11.1.so
0075f000-00762000 rw-p 00000000 00:00 0
007de000-007df000 r-xp 00000000 00:00 0 [vdso]
00a15000-00a30000 r-xp 00000000 08:01 3167 /lib/ld-2.11.1.so
00a30000-00a31000 r--p 0001a000 08:01 3167 /lib/ld-2.11.1.so
00a31000-00a32000 rw-p 0001b000 08:01 3167 /lib/ld-2.11.1.so
00f00000-00f07000 r-xp 00000000 08:01 267504 /lib/tls/i686/cmov/librt-2.11.1.so
00f07000-00f08000 r--p 00006000 08:01 267504 /lib/tls/i686/cmov/librt-2.11.1.so
00f08000-00f09000 rw-p 00007000 08:01 267504 /lib/tls/i686/cmov/librt-2.11.1.so
00f4b000-00f60000 r-xp 00000000 08:01 267502 /lib/tls/i686/cmov/libpthread-2.11.1.so
00f60000-00f61000 r--p 00014000 08:01 267502 /lib/tls/i686/cmov/libpthread-2.11.1.so
00f61000-00f62000 rw-p 00015000 08:01 267502 /lib/tls/i686/cmov/libpthread-2.11.1.so
00f62000-00f64000 rw-p 00000000 00:00 0
08048000-080b6000 r-xp 00000000 08:01 197512 /home/johan/Desktop/vgmplay/VGMPlay
080b6000-080b7000 r--p 0006d000 08:01 197512 /home/johan/Desktop/vgmplay/VGMPlay
080b7000-080ba000 rw-p 0006e000 08:01 197512 /home/johan/Desktop/vgmplay/VGMPlay
080ba000-0934d000 rw-p 00000000 00:00 0
09cfa000-09d1c000 rw-p 00000000 00:00 0 [heap]
b7700000-b7721000 rw-p 00000000 00:00 0
b7721000-b7800000 ---p 00000000 00:00 0
b7835000-b7837000 rw-p 00000000 00:00 0
b784d000-b7850000 rw-p 00000000 00:00 0
bfaa6000-bfabb000 rw-p 00000000 00:00 0 [stack]
Aborted
johan@ubuntu-laptop:~/Desktop/vgmplay$
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Tue Jan 04, 2011 3:55 pm
@SmartOne: I reduced to volume by 2. (only if YM2612 is used)
The next update will include this. It's quite hard to find a tracks that use all channels at the full volume.
In VGMPlay you'll still have to reduce the volume via ini-file.

@spotUP: Ubuntu has a problem with VGMPlay. And I absolutely don't know why.
Your Ubuntu crashes and mine doesn't find the ini-file and fails to open the sound device.
Sorry, but I still can't help you.

Please ask someone to get it running and post the a diff-file.
  View user's profile Send private message Visit poster's website
SmartOne
  • Guest
Reply with quote
Post Posted: Tue Jan 04, 2011 5:11 pm
Thank you. Do you notice the DAC pitch issue? It would be best to run at the actual hardware rate and resample. This is a classic Genesis music issue.
 
SmartOne
  • Guest
Reply with quote
Post Posted: Tue Jan 04, 2011 7:10 pm
Alisia Dragoon "Stage 1-2" plays incorrectly. The same VGM plays perfectly in Fusion.
 
SmartOne
  • Guest
Reply with quote
Post Posted: Tue Jan 04, 2011 9:22 pm
The DAC issue maybe isn't the DAC. It's usually percussion in the FM channels. Listen to Monster World IV "Main Theme" for an obvious distinction. It's Tone 3 in that case.
 
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Tue Jan 04, 2011 9:30 pm
You're right - the Alisia Dragoon vgm sounds terrible with MAME and GME core (all these cores are based on Genesis Plus GX). The old Gens core does it right. (I'm using VGMPlay to test.)

I didn't notice the DAC-pitch-bug. But I solved it. (I need to disappoint you, but VGMPlay and in_vgm do this right.)
The solution: when I tried to compare the output of in_vgm/VGMPlay with Fusion (of course a vgm -> ROM conversion) with Audacity I noticed, that both go out of sync quite quickly.
To get the vgm-from-ROM in sync with VGMPlay's log, I had to increase the sample rate of the former to 44812 Hz.
This would explain the DAC-pitch-issue. And it would also explain that I didn't hear a difference, when I compared some Pier Solar music (game and vgm).

EDIT: Tested the Monster World vgm. Again, the old Gens core sounds better than MAME/GME. I'll reinclude it in the next in_vgm update.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Feb 2009
  • Posts: 110
  • Location: Toulouse, France
Reply with quote
Post Posted: Wed Jan 05, 2011 9:48 am
ValleyBell wrote

EDIT: Tested the Monster World vgm. Again, the old Gens core sounds better than MAME/GME. I'll reinclude it in the next in_vgm update.


I don't have any problem with those games you mentionned in Genesis Plus GX and the old Gens core is definitively less accurate than the MAME core so I don't think reverting back is a good idea.

You should probably define more specifically what you mean by "sounds better" but this is very likely an issue with samplerate and update timings: gens does basic interpolation if hq_ym2612 is enabled, while it must be done externally with MAME core (the "frequency" ratio must be set to 1.0 and the output converted to host samplerate using quality resampling). Also gens does "special updates" when certain writes are performed which is not accurate but can help rendering some special effects. With MAME core, you need to do this externally as well (ideally, this should be done before each new data register writes, using the correct number of cycles elapsed to render a suitable number samples at the native rate)
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Jan 05, 2011 3:18 pm
You're right, it has something to do with the timing. Rerecording the vgm2rom makes it sound better. (attached an vgm that sounds bad with VGMPlay)

To solve the timing-problem, I'm calling ym2612_update with a zero-buffer before I write a data-register. It just calls refresh_fc_eg_chan for all channels.
Adding update_ssg_eg_channel-calls for each channel seems to fix the problem with the attached vgm.

What should I do?
Thanks for the help.

  View user's profile Send private message Visit poster's website
  • Joined: 06 Feb 2009
  • Posts: 110
  • Location: Toulouse, France
Reply with quote
Post Posted: Wed Jan 05, 2011 4:38 pm
You shouldn't have to modify the YM2612 core functions (unless you exactly know what you are doing), maybe you fix some stuff this way but you will surely broke other stuff.

I'm not very aware of the VGM format but each FM writes should be associated with a timing value (clock count ?). The idea is to keep track of the current chip execution and everytime a write is performed, run the chip up to the write position.

Running the chip is made using the YM2612_update function: the ptr should be the current position in the output buffer (which should be updated everytime after you call the update function and reseted after you flush the buffer) and the length should be calculated using the current chip position and the aimed position.

For example, if current cycle is 0 and next register write cycle value is 8964, the number of samples to update is (8964 - 0)/cycles_per_samples

with cycles_per_samples = clock / FM_rate

FM_rate is the original chip sample rate if you are using hq_ym2612 (and additional resampling to the output samplerate).
If you are not using hq_ym2612, FM_rate is your output samplerate.

clock is the input clock, which is the base unit for FM writes timestamps

When using genesis VCLK (7.67 Mhz) as reference, in hq_ym2612 mode, FM_rate=clock/144 (i.e cycles_per_samples = 144)
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Wed Jan 05, 2011 5:28 pm
I understand what you want and I'm already doing this in some way, but the sample rate of vgms is slightly lower (44100 Hz) than the one of FM chips. (That's the problem, I guess.)
Usually I'm generating 1-2 FM samples, depending on the current counter value. Then I'm adding one to the vgm sample position and do the next chip writes, if neccessary.
  View user's profile Send private message Visit poster's website
SmartOne
  • Guest
Reply with quote
Post Posted: Mon Jan 10, 2011 4:07 am
The accuracy is there in emulators. It comes down to getting a proper implementation for the standalone players. Hopefully what Eke describes can be properly implemented.
 
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Mon Jan 10, 2011 9:02 am
SmartOne wrote
The accuracy is there in emulators.

Right, but actually not in the roms.

And there's an important difference between emulator and player.
The player "stops" the chip, sends all commands and runs the chip for some samples. That's very accurate. (just vgms aren't)
The ROM (in an emulator) sends the commands while the emulator continues to emulate the chip. That's a lot more "real" (because it's real-time), but actually not as accurate as the player.
It seems to take away the timing issues, but I still don't trust the VgmPlay ROM because it plays at 43400 Hz (and because rerecorded vgms seem to sound fine although the original ones don't).

Another thing I noticed: The vgms logged by any MegaDrive emulator (including Kega Fusion) are logging scanline-accurate vgms. (That applies only to non-DAC commands.) That means that there are up to 7 commands at sample A, then a delay of 2-3 samples and then another set of commands at sample B.
When using MAME I get very many 1-sample-delays.

SmartOne, try this update.

EDIT: Found the real problem. It's the beginning of the vgm. All commands that setup the instruments and where timing seems important are at sample 0 (because of trimming). I recorded an vgm from the Alisia Dragoon rom and it sounded as it should (with the old version).
VGMPlay_Update.rar (112.5 KB)

  View user's profile Send private message Visit poster's website
SmartOne
  • Guest
Reply with quote
Post Posted: Mon Jan 10, 2011 4:33 pm
So far, so good! Thank you! Aside from maybe some channel balance differences from Fusion, it sounds great. When can we expect an update to the Winamp plugin? ;)
 
SmartOne
  • Guest
Reply with quote
Post Posted: Mon Jan 10, 2011 11:42 pm
Monster World IV "Main Theme" is still incorrect.
 
Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next



Back to the top of this page

Back to SMS Power!