vgmrips

The forum about vgm files
It is currently 2017-11-20, 9:34:54

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 186 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next
Author Message
 Post subject:
PostPosted: 2016-05-17, 16:52:16 
Offline

Joined: 2014-12-30, 1:38:48
Posts: 60
VGMTrans feels like a waste. Nothing happens when attempting to open certain files.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-05-17, 17:46:35 

Contributors Contributors
Staff Staff
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 222
VGMTrans doesn't work with VGM files. Look at the readme for supported formats. Try GBA/DS ROMs and SPC files. And they only work if the sound driver is supported. Some CPS2 QSound games also work, but the ROM filenames inside the zip have to exactly match the ones in the xml.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-08, 16:10:01 

Contributors Contributors
Offline
User avatar

Joined: 2012-01-03, 2:10:28
Posts: 274
ES5506 is not supported?
vgm_cmp and vgm_sro does not work.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-08, 19:28:05 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Offline
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 2843
Location: Germany
Sorry, but yes - there is no support for ES5505/06 at all.
I made a few test rips (to verify that they play fine in VGMPlay), but haven't worked on the tools yet. (Especially the ES5506 is going to be a challenge due to 24-bit data split over multiple VGM commands.)


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-08, 20:08:14 

Contributors Contributors
Offline
User avatar

Joined: 2012-01-03, 2:10:28
Posts: 274
Okey, May I then submit the ES5505/06 packs? (Do not optimize)


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-10, 7:26:48 

Contributors Contributors
Staff Staff
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 222
ES5506 rips from SSV games work fine (Twin Eagle 2, Dyna Gear, Vasara etc). I would guess other games like Macross Plus would also work.

Taito ES5505 do not work at all (not only are the files huge, but they play incorrectly), so don't bother.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-10, 9:29:15 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Offline
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 2843
Location: Germany
Give me two weeks and I'll try to at least get vgm_sro to support the ES5506.
Looking at the ES5506, I'm thinking about adding an additional VGM command for them. (And I need to correct myself - commands have 32-bit data, though that doesn't really make a difference.)


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-11, 21:09:33 

Contributors Contributors
Offline
User avatar

Joined: 2012-01-03, 2:10:28
Posts: 274
Okay, I will wait.


ctr wrote:
ES5506 rips from SSV games work fine (Twin Eagle 2, Dyna Gear, Vasara etc). I would guess other games like Macross Plus would also work.

It is probably Only the Super Real Mahjong P7 is not correctly play in SSV games.
Sample vgm :Super Real Mahjong P7 - Opening
http://www.mediafire.com/download/8pvl6 ... srmp7_0.7z

Sample mp3 :Super Real Mahjong P7 - Opening
http://www.mediafire.com/download/c54wc ... mp7_op.mp3
The source of the MP3 is a board recording of Nico Nico Douga.
http://nviewer.mobi/player?video_id=sm9334332

When comparing both vgm is missing is sound.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-06-11, 22:11:31 

Contributors Contributors
Staff Staff
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 222
It seems like that game uses bank switching for the ES5506 samples. Even though there seems to be code in MAME for it, it does not sound properly there either. Strange...


Top
 Profile  
 
 Post subject:
PostPosted: 2016-08-04, 16:42:49 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Offline
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 2843
Location: Germany
I just updated the tools in the OP.
Not much has happened really, except for a few fixes, Virtual Boy VSU support in vgm_cmp and SCC(+) support in vgm_trim.
It should also warn you about a broken zlib DLL now instead of silently generating broken VGMs.

ES5505/6 support didn't made it, sorry. (I partly added it to vgm_sro, but the ROM banks are handled in a very crappy way currently. I'd like to redo parts of the emulation here.)


Top
 Profile  
 
 Post subject: Thank you!
PostPosted: 2016-10-10, 20:35:56 
Offline
User avatar

Joined: 2015-06-08, 20:42:22
Posts: 30
Location: Argentina
Thanks for the updates! ^^

EDIT: I just tried the opl_23 tool and I finally figured out how to successfully convert OPL2 VGMs into OPL3. I may begin publishing my own DOS packs soon! :mrgreen:


Top
 Profile  
 
 Post subject: Not a very good start...
PostPosted: 2016-10-11, 3:40:40 
Offline
User avatar

Joined: 2015-06-08, 20:42:22
Posts: 30
Location: Argentina
With this particular VGM I tried converting it to OPL3 and it took away more than half of all the sound, so I decided to leave it as OPL2.

BUT, when I trimmed the OPL2 VGM, it did that same thing, more than half of the sound just disappeared.


Attachments:
File comment: Trimmed OPL2 VGM (all I did was apply vgm_trim to the previous one)
drax-hybrid_trimmed.vgm [71.6 KiB]
Downloaded 12 times
File comment: Original untrimmed OPL2 VGM
drax-hybrid.vgm [152.75 KiB]
Downloaded 13 times
Top
 Profile  
 
 Post subject:
PostPosted: 2016-10-11, 9:56:42 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Offline
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 2843
Location: Germany
Did you happen to log that song with the "normal" DOSBox instead of the modified one we have on vgmrips?
The "normal" DOSBox uses a vgm_cmp like algorithm* when logging and that often causes instrument definitions to be incomplete even when starting a song. (and it sometimes screws frequencies up when looping)
The trimming points look good from what I saw by comparing the VGMs via vgm2txt.

Anyway, why were you trying to convert OPL2 to OPL3? There is really no reason for that. If DOSBox writes a DRO for OPL2, the sound uses none of the OPL3 features, so it plays back on identically OPL2 and OPL3.
(And opl_23 can only convert between DualOPL2 and OPL3 anyway.)

* in fact, the VGM you posted gets only 3 bytes smaller when using vgm_cmp on it, so I'm pretty sure DOSBox did some optimization while logging.


Top
 Profile  
 
 Post subject:
PostPosted: 2016-10-12, 3:02:54 
Offline
User avatar

Joined: 2015-06-08, 20:42:22
Posts: 30
Location: Argentina
ValleyBell wrote:
Did you happen to log that song with the "normal" DOSBox instead of the modified one we have on vgmrips?
The "normal" DOSBox uses a vgm_cmp like algorithm* when logging and that often causes instrument definitions to be incomplete even when starting a song. (and it sometimes screws frequencies up when looping)
The trimming points look good from what I saw by comparing the VGMs via vgm2txt.

I believe I was using the one posted here in the forum, but I'll download it again just to make sure.

ValleyBell wrote:
Anyway, why were you trying to convert OPL2 to OPL3? There is really no reason for that. If DOSBox writes a DRO for OPL2, the sound uses none of the OPL3 features, so it plays back on identically OPL2 and OPL3.
(And opl_23 can only convert between DualOPL2 and OPL3 anyway.)

Because when you set OPL mode to auto (which I think is already like that by default), DOSBox behaves with the kind of backward compatibility that a Sound Blaster 16 with the physical OPL3 chip does when playing OPL2 music. It does sound differently in DOSBox than it does when you convert a freshly logged .DRO to .VGM.
Changing the OPL mode to dualopl2 did it for me. I did some little testing with the intro music from Darkseed, and converting dualopl2 to opl3 gave me the sound I was looking for - what you actually hear while playing the game in DOSBox with the OPL mode set to auto, and I think, the sound you'd get if you played the game with a Sound Blaster 16 with a physical OPL3 chip instead of an OPL2.

ValleyBell wrote:
* in fact, the VGM you posted gets only 3 bytes smaller when using vgm_cmp on it, so I'm pretty sure DOSBox did some optimization while logging.[/size]

In that case I'm definitely going to recheck the download, or use the SVN build if the problem persists, lest you don't recommend it?

EDIT: I downloaded DOSBox again from here and the problem persists. Here are the files attached from my second attempt at trimming it (at which I realised that the actual cycle was a bit ahead of where I had set it - not that that made much of a difference).
Attachment:
File comment: Raw DRO log, freshly converted VGM, and trimmed VGM.
DRO_VGM.zip [35.82 KiB]
Downloaded 14 times


EDIT #2: This particular DRO/VGM log worked with the DOSBox SVN Build R4000 available here. This particular build waits until receiving any OPL commands, resulting in an automatically trimmed DRO log (at the beginning), to which I added a 3072 samples silence just in case.
Attachment:
File comment: New logs with the DOSBox SVN build R4000.
DRO_VGM_SVN.zip [36.81 KiB]
Downloaded 14 times


Top
 Profile  
 
 Post subject:
PostPosted: 2016-10-12, 9:53:53 

Staff Staff
Programmers Programmers
Musicians Musicians
Contributors Contributors
Offline
User avatar

Joined: 2011-12-01, 20:20:07
Posts: 2843
Location: Germany
Hmm... there could also be the rare case of the sound engine itself optimizing out commands. (Which seems to be the case for this intro.)
In that case, you can use
Code:
vgm_trim.exe -state
to write additional data to the beginning of the VGM.

About the SVN build: The detection of DualOPL2/OPL3 in the official build is weird and broken, that's why I don't use it. It also doesn't always trim correctly. (It worked fine in your case.)

There is no need to add additional silence to the beginning. You shouldn't do that as there are no benefits. (The sound chip doesn't get more time to initialize, because initialization just takes place at a later time, just in case that's what you wanted.)

kyusawamura wrote:
ValleyBell wrote:
Anyway, why were you trying to convert OPL2 to OPL3? There is really no reason for that. If DOSBox writes a DRO for OPL2, the sound uses none of the OPL3 features, so it plays back on identically OPL2 and OPL3.
(And opl_23 can only convert between DualOPL2 and OPL3 anyway.)
Because when you set OPL mode to auto (which I think is already like that by default), DOSBox behaves with the kind of backward compatibility that a Sound Blaster 16 with the physical OPL3 chip does when playing OPL2 music. It does sound differently in DOSBox than it does when you convert a freshly logged .DRO to .VGM.
Changing the OPL mode to dualopl2 did it for me. I did some little testing with the intro music from Darkseed, and converting dualopl2 to opl3 gave me the sound I was looking for - what you actually hear while playing the game in DOSBox with the OPL mode set to auto, and I think, the sound you'd get if you played the game with a Sound Blaster 16 with a physical OPL3 chip instead of an OPL2.

There should be no differences between using the OPL2 itself or using the OPL3 in OPL2 fallback mode. If there are audible differences, it's probably due to emulation oddities.
Anyway, feel free to post examples. ("oplmode=auto" results in "oplmode=opl3" for SB16, btw.)
Using DualOPL2 just duplicates all commands in most games. I think I've only seen proper DualOPL2 support in XMI-based games so far.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 186 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: Google Feedfetcher and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group