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
[VGM pack] Streets Of Rage 2 (SMS)Posted: Mon Feb 09, 2015 5:07 am
Last edited by TheAssassin on Sat Feb 21, 2015 8:18 am; edited 1 time in total
Wasn't really sure where to put this but I just noticed with Streets Of Rage 2, the SMS version has a slightly different sounding character select music to the GG version.
I assumed the music between the SMS and GG versions were identical, but this is at least is one difference. Perhaps there are more differences?
||Posted: Mon Feb 09, 2015 11:02 pm|
It could be. Only the gg version has been posted. Some games (like the tom and jerry we worked on recently) might have differences among the tracks. So far, only three packs on the site are shared between the systems (and one of them integrates the differences into one pack).
Both versions have a sound test, so you could easily test for this if you like.
edit: I went and compared the two quickly. All themes except the character selection screen sound the same between versions, though i did not listen for minute details or variations. It seems to use different sounds. Also the GG version has two extra themes (BGM 16-17)
BGM 12 is the character selection screen.
||Posted: Wed Feb 11, 2015 5:22 am|
Thanks sherpa. I haven't directly compared the GG and SMS soundtracks myself, but I'm pretty familiar with the SMS game and haven't noticed any other differences when listening to the GG VGM pack so you're probably right.
Like you say the character select themes are very similar just seem to have slightly different sounds or tones used. Weird they would even bother making such a minor change.
Any chance you could do a quick rip of the SMS select screen music sherpa? Seems it's the only thing missing to finish the combined GG/SMS VGM pack, (plus this just happens to be my #1 favorite SMS soundtrack ever - so it's gonna bug me if I know this is missing! lol).
Happy to do any retagging if it helps.
||Posted: Wed Feb 11, 2015 1:49 pm|
'fraid it's not so simple. Streets of rage for SMS was only released in pal regions. Strike 1. I was looking up japanese track info but it looks like even the composer gives them english titles in the collections he releases in japan. so that's that. At 50hz everything is slower. At 60hz, it sounds almost like the gg version. For the title theme, there is a slight difference, what begins as a mild phase in the beginning, becomes more echo-like by the end of the first loop, and more noticable by the end of the second. The difference is more than 1470 and less than 1764, but the offset is incremental and regular, it doesn't seem to be a looping issue.
On the other hand, the character theme lines up perfect until the loop point then Blamo! 3800+ sample differences. I did not check, but it could be that Maxim cut his loop point short as one explanation. I have no idea when this pack was made, or if it is/was frame adjusted when originally released. Or if lpfnd even existed. Frame accuracy tends to offset the music at several points early on and align it proper later on. Doesn't seem to be the case here, but it has a short loop, so who knows. That's why I don't like to use the vgm_facc. Some exceptions are when I am in a rush and a song doesn't loop. The ear won't be able to tell anyway. These differences are only obvious when playing things back side by side.
My other guess for tempo changes is that there is another table or formula used for tempo in 50hz and 60hz that needs to be adjusted as well to the cycle differences, and maybe once you switch, some of those might not round properly. Or it could be a few extra lines of code steal a bit of time. Idon't think this is actually possible, but I don't actually know what ellements can affect the music. The faster version is how it's supposed to sound (GG was the original). The slower one is probably the way you heard it.
I gave it a shot since it was only one track, but this is too much of a puzzle atm. I might not mind if there was nothing else in the queue, but there's quite a bit, and it's probably going to be a while before I resume vgm work.
I'm not sure how to tag it, or if all tracks would be retagged, but due to tempo differences, probably not. They're practically different songs even if everything else is the same, the tempo gives a different feel.
Anyway, posted the two versions. I assume you remember the slow version. These are probably just for your enjoyment.
edit: Ok, I took a peek out of curiousity, and maxim's loop is short. I took a look at the text output and was confused. Maxim's has the GG stereo enabled. Mine doesn't. Do you need to insert it manually? None of my gg based sets have that command. How would inserting it change the offset? Is there a tool to take the guesswork out of editing the vgm at the proper locations? Also the text outputs look nothing alike. I guess the vgms outputed now don't resemble the older ones even if they sound the same.
Also, this has been bugging me-but since maxim developed the vgm up to 1.5 (and his vgm is version 1.5) why does meka only support 1.10? Is there an enable gg stereo setting in the emulator or must it always be added manually?
I was going to compare the two texts to sarisfy my curiousity, but i couldn't find any common areas between the two which is baffling. I used both vgm2txt and vgmtool r5 but no luck there. I didn't dive into the hex since i have my attention on other things currently. But this is a puzzle. Either way, unless the emulators logged differently back in the day (and they probably did) this is more complicated than a simple look see. It also brings to mind a common theme while trimming. I often spend a bit of time on some vgms when the error is <2K samples and often whether it's this side of 735 or that, mainly when loops aren't 100% clean. This track gives lpfnd no trouble, which makes me think this was done in the days before vgm2mid and lpfnd. Or honest human error. I know I have some tracks I just cut according to the waveform (which isn't always right) after i've spent to much time belaboring which is the right loop point. Either way, no one will ever notice. Even heuristics won't detect a track that is too short, but it might if too long. When in doubt, it's better to cut short. I'm sure people familiar with the ost haven't noticed. I would have never known if i hadn't looked so closely.
edit 2: actually looked at CRVs sticky ost from 10 years ago...He mentions this track and others...so this pack is that old? Which makes me wonder...how did he even develop the list? It would seem that logging and looping a track takes much less time generally than noticing there is an error in a track...is there a tool available or private that detected errors in vgms already made? I was thinking it would be nice to have something like that a while ago. When you're working on a pack there' alot of human judgement, and ultimately, you probably trim it the way you think best, but it could be after the fact, you might have an easier time evaluating your work when you aren't so focussed on getting it done and done "right". Why weren't the corrections posted? Were they, and this was one of the packs that was neglected?
It would be nice to be able to automate alot of this. I think lpfnd is pretty good for what it does (detect matching patterns) but there are many simple things that can throw it off that don't confuse the human ear (and some that don't throw it off that do confuse the human ear), but I keep trying to imagine better solutions, what they might be, I'm not sure.
||Posted: Thu Feb 12, 2015 2:35 am|
Oh yeh I forgot about the speed, you're right SOR2 was only released on PAL SMS so the entire pack would need to be redone from scratch to make a true SMS pack. The GG pack was completed around 2005 (though it may have been worked on before then), I remember because I was the one that requested it! Well, I actually asked for the SMS version, but Maxim only offered the GG version so I thought beggars can't be choosers.
And yeh the 50hz versions are definetely what I remember, the 60hz ones will always sound too fast to me. I appreciate you doing the SMS character select for me, it'll fill the gap in my collection at least until a full SMS pack is released.
I hadn't looked at CRV's old sticky before but yeh he has listed a bunch of tracks from the GG pack as having errors! So even more problems :( .I guess the only reason the errors haven't been corrected is the same reason new packs aren't released very often - lack of volunteers?
Oh and regarding the track titles, I have scans of all the official Japanese soundtrack CDs for the series, so could easily do any tagging needed, if and when you (or anyone) has time to do a complete SMS VGM pack.
||Posted: Thu Feb 12, 2015 8:44 am|
|I didn't rip the pack, I just tagged and packed it. I think it has heavy stereo effects, making the SMS version even more different.|
||Posted: Thu Feb 12, 2015 9:37 am|
Man I thought my SMS VGM wishlist was finally cleared after 10 years, I never realized there were so many differences between the SMS and GG versions of Streets Of Rage 2!
How do you guys even notice all these differences? I've listened to the GG VGM pack loads and played the SMS game loads and I never noticed any other differences apart from the character select theme and the extra 2 tracks. Not saying you're wrong but I'm just wondering how I missed them. Is it just going by ear or do you have some program/tools to check the differences?
||Posted: Thu Feb 12, 2015 9:57 am|
|Just ear. Game Gear stereo is all or nothing so it's very noticeable with headphones.|
||Posted: Sun Feb 15, 2015 9:02 am|
Not sure if you were asking me as well, but my ears largely didn't notice. If I hadn't sought to compare the differences between the character selection tracks I would not have noticed. I think my ear was a bit sharper than usual from comparing the Heavyweight Champ versions which were very similar in tempo, but I noticed something was off.
All my statements came from ultimately looking at things at the wavelevel. I think going forward that will be my preferred method. It's alot faster to cut the wrong place and see how it lines up then adjust than it is to try to fiddle with the text output when the commands aren't exact. Of course the values you should use will come from the txt most of the time, but sometimes the waveform is the better model..sometimes it's not.
I wouldn't take it too hard. Most people didn't notice, or if they did they stayed mum about it. Part of my challenge is that I am not familiar with alot of this music, so I cannot rely on memory to tell me if somethings off. Also developing your ear is like anything. If you use it, it gets better. Even if you only improve it short term, then neglect it for a while, the mind is automatically working on improving things even while you're doing nothing.
Tempo is relative, so if you have nothing to compare it to, it's easy not to notice something is off. This raises the question as to whether it's even possible to rip an ideal pack with games in different regions. Sometimes the differences are so sublte you'd barely notice unless you looked at the wavefore. Sometimes it's also more of an intuition than knowing somethings off.
Of course, you can train your ear to be sensitive to minute variations, in which case some subtle things may become not so subtle. I have a pretty bad ear because I rarely corrected my misperceptions or isolated a source of confusion. But I've found what I've developed, even if it was many years ago, with scarcely any use, I keep.
Maybe you could listen to some of the other osts and try to detect which ones have errors? You could train and contribute at the same time :)
||Posted: Sun Feb 15, 2015 4:55 pm|
Yeh I was asking both of you. Like you say part of it is listening but part of it is memory like in my case.
I have been listening to SMS packs a fair bit lately and since you mentioned looking for errors, I'm pretty sure there's something wrong with the Golden Axe VGM pack, specifically the Wilderness track. It seems OK when playing at 60hz, but when you play it at 50hz, around 0:40 some of the notes don't seem to play correctly. I think Maxim or someone has already noted a few other problems with that pack too.
Also if you see my notes on the Main forum (http://www.smspower.org/forums/15255-DoAllPALGamesRunAt50hzOnARealPALSMS) I've identified 3 PAL games for which the music plays at a 60hz rate, in-game (and yes that's when running the game at 50hz PAL) which to me was quite an intriguing discovery.
||Posted: Tue Feb 17, 2015 10:29 pm|
Thanks for jogging my memory. So according to your tests my original pack of Robocop vs the terminator was correct?! This doesn't flesh out in my tests with the emulator. Are these tests on actual hardware? Cause that would be the winning authority. I was hoping the emulator would treat them like in a machine if this is not the case.
I took a quick break to work through the pack. Think it took less than an hour since I didn't go through my usual rigourous QA verifying session.
This was an easy pack to trim. lpfnd was a hit every time !.
I did not challenge its findings or test listen or anything. If it said the loop started at :23 then that's how I trimmed it. Normally I would go to town just to see if it was true (usually is). Odds are most if not all will be correct.
I will not be tagging these anytime soon. I know I've mentioned this before, but you could do a lot of this yourself with a little bit investment.
If you want to check the loops yourself in a waveviewer, I can post the originals. Otherwise I'll get around to it some day. I've been meaning to write some tutorials on the process. Best results method is currently:
If sound test or trigger avalable
1) set it up so you're ready to log
2) Freeze meka (F12)
3) start the log
4) change the value in memory or hold down the button to start song playback.
6) Hold f4 till it hits 400hZ.
7) Leave it logging for a bit 30s=~4min. enough for most loops. Log more than you need 2-3 loops is good.
8)stop the log output and set the next one up, and start logging.
9) while it's logging, rename the file to match the id, unless you know its title already, and your intended final order. Use lpfnd if you have enough time.
10) Continue until all songs are logged
1)drag to lpfnd. Leave window open. Make sure you enable copying to/from the command window to make your life easier.
2) Press pause if it finds ! to stall the program and save resources
3) Drag the file to vgm_trim. If you were able to log as above (not always possible) the start point is 0. You can set it to one frame value 735 ntsc/882 pal which should be the start. I leave a little extra, so I set it to 0.
4) paste in the other loop values
5) repeat for other tracks. If there are problems, you'll have to use vgm_txt and export the file to wave using a compatible player with that ability. vgm_play works. I use foobar.
Tagging: I now recommend vgmtoolbox over vgmtool r5. Makes mass tagging alot easier. No general guide for this. Find out as much info as you can, use real name instead of aliases, and follow the guidelines listed on this site for tagging.
Producing extras: same as above. you could probably write a cmdline script to tag the files based on the contents of the txt file, but I don't know how to do that, so that wouldn't be part of the guide.
Easy to forget: vgm7z is uncompressed vgms 7zipped. final zip is compressed vgms gzipped, renamed to have a vgm extension. Picture is screenshot as square as possible. Print screen in Meka. Resize canvas using a free program like irfanview or your own tools, and fill out the empty space. Name everything the same as your files. GG should have that after the base name. So should FM.
I will not be checking these for a while and will not be tagging them for even longer. They're up if anyone wants to work on that-or just listen.
||Posted: Wed Feb 18, 2015 6:15 am|
My tests were just using MEKA, I don't have a real SMS anymore and nobody who does have one offered to help, so using MEKA was my only option. I set the TV Type to PAL and the rate to 50hz, then compared, by-ear, how the in-game music sounded in comparison to the VGM packs, firstly with inVGM set to 50hz, then with inVGM set to 60hz. For all the games I tried, the in-game music speed matched the VGM packs playing at 50hz, except for Robocop Versus The Terminator, Sonic The Hedgehog 2 and Land Of Illusion Starring Mickey Mouse. With those three, the VGM packs playing at 60hz matched the in-game music speed. I don't understand the technicalities but Maxim mentioned that some games have some kind of compensation so the music and/or gameplay don't slow down as is usual with PAL.
Additionally the results of my experiments DO match my memories of playing these games on a real SMS, as a kid. Robocop Versus The Terminator was actually what prompted my experiments here, as when I played the VGM pack at 50hz, the music sounded slower than I remember it being on my real SMS as a kid.
Once again I am indebted to your kindness sherpa, thanks so much for doing these SOR2 SMS rips. I will have a listen later and see if I notice any problems. As I mentioned before this is my #1 favorite soundtrack on SMS! The tracks are often quite distinct from the Genesis version and in a lot of cases I much prefer the SMS arrangements. Particularly "Go Straight" ("BGM 1" in your pack).
Thanks for the tips too, perhaps might have a play around at some point. I'll see what I can do with tagging these tracks too, should be pretty easy for me.
Posted: Fri Feb 20, 2015 3:09 pm
Last edited by TheAssassin on Sat Feb 21, 2015 12:31 pm; edited 1 time in total
|EDIT: see posts below for most up-to-date VGM pack|
Posted: Sat Feb 21, 2015 5:12 am
Last edited by sherpa on Mon Feb 23, 2015 4:29 am; edited 1 time in total
You didn't mention whether or not you listened to the tracks, and your opinion, if you noticed anything.
Added Japanese tags for Game Title, Music Author and System since they were missing. (In general, the only reason not to add Japanese tags is if they don't exist.) Song titles left as is since only English variants have been found (including collections by the composer sold on japanese websites).
Took a mild break to tag since I was working on other packs anyway, and I've hit a wall in my attempts to figure out how to access the sound engine in most games where a trigger isn't handily available. I've been revisiting the z80 instruction set, but still have huge gaps in my understanding of how assembly manages..Anyway back on topic.
I'm including the originals in case you'd like to verify them yourself. Not sure this is technically needed. Many of the existing packs have issues, and a lot of people don't know enough about the tools and how they work to challenge the results anyway. Probably better that way.
Normally you verify at the point of trimming using vgm2txt and whatever other tools (usually at least a waveeditor) you use. I recommend bypassing all that and exporting the files to wave using a compatible tool (winamp, vgm_play, foobar). Then load them up in a wave viewer (I use audacity).
If you look, you can see the files line up well toward the end of the second loop. Success. The loop file is the same as the original up until the fadeout point (beginning of third loop).
You can also hex compare the waves (might actually be faster). Mild visual differences may not translate to actual differences in the file. I haven't tested this vigorously, but it seems to be the case. Also had an instance where the wave file didn't match up on one occasion, and when i reexported and compared, it did..I don't think it was human error, but it could have been that, or a bug in one of the programs along the way. User beware.
So two tracks 1st two verified proper. Not sure if anyone will really grouse over this, but they're up for the interested. I'm starting to lean in the direction of preferring fast work to detailed laborious work. The proof isn't in the pudding. Generally I find issues that either have no clear solution (loops that aren't actually loops) or spend alot of time debating mini amounts of sound the ear will not hear.
Finishing the tagging process and extras (plus this post) took much longer than trimming the original set (50 min logging and trimming by timestamps)-and I wasn't as lackadaisical as I might portend. I just excluded using any of my personal tools for a second opinion or triple checking everything.
edit: Is there a way to make the image show up in the post? oh well.
Mini Tutorial for verifying against original.
It's going to be a bit more challenging since the old files have nondescript names, and the new ones are named correctly. But..
1) Load untrimed original and export to wav (using compatible tool)
2) Load trimmed version and export to wav
3) Open both files in the same wave viewer (audacity is shown)
4) If necessary convert to mono from menu to make comparison simpler
5) Zoom in a bit (resolution should be ~.10 second) Make sure you are viewing time in samples (not seconds/millisecods) and that the sample rate is 44100. Normally you will not have to worry about the latter, but tools vary.
6) Line the waves up so they match at start (I think these files all do, in Audacity you can use he sideways arrow tool <--> to slide it into alignment.
7) Play for a bit at the beginning to make sure they match up. You will probably hear some phase effects unless they match up exactly but that's ok.
8) The first test is how they line up a few seconds in (if they don't it's not a looping issue, it may be a bug or something else-recheck they have the same starting point) An exception to this is if a file was not trimmed according to vgmtxt values or not esactly divisible by the frame rate and vgm_facc was applied (as it should be) and it adjusted the file in bits. In that case, you may have some offsetting earlier on in the file, but it should be lined up long before the first loop concludes, and for tha majority of the track. as far as i know vgm_facc never affects the loop point.
9) The important point is at the loop point and after. Sometimes it's about 1/2 the playback rate, but often it's a bit more lopsided in favor of the first loop being slightly longer (not necessarily in seconds). Use the pack extra, txt for info on loop sizes.
10) Zoom in if necessary. Differences will be in multiples of 735/882 samples depending on the encoding. If it's 735 or more, congratulations, you've found a badly trimmed file. Feel free to redo it yourself, or report it. If the trimmed file's second loop starts AFTER the second loop of the original, it was trimmed long..if it starts BEFORE (will be more common) it was trimmed short. If it matches up not at all, the job was totally botched and should really be redone.
11) If you're a purist and not ashamed of it, the first two cases should also be redone. Just make sure it wasn't user or software error. To give a sense of time 2205 samples are .05 of a second. Most ears will not notice until it starts to creep at to .1 to .2. Larger errors probably indicate that the txt log was not consulted at all, and the user probably trimmed without paying close attention to the wav. Certainly not out of the realm of possibility. You probably won't notice anyway, unless something gives it away, like a quick flurry of notes being suddenly cut, or clicks and pops because of where it was looped.
12) If they match and continue to match past the midpoint, up to the fadeout, congrats, you have confirmed an ideal trim. All the files in this pack registered a ! ideal loop in lpfnd, so the odds of a bad loop are less than usual..but it can still happen. ! doesn't mean it's right, it only means it found matches throughout that entire section and wasn't terminated by an eof or other reason.
You can apply this as a safeguard in general. It is usually much faster to cut, trim, export and compare than to guess at a loop based on text (though that can help if you know what you're looking for).
Well that's another mini tutorial.
||Posted: Sat Feb 21, 2015 12:30 pm|
Ah yes I forgot to mention I have listened to the pack for several hours over the last couple of days and didn't notice any problems. But this is just going by memory and by ear.
Thanks for tidying up the tags sherpa. I think you're right that most people don't know how to check rips for issues. It's a shame the SMS soundtrack community isn't more active as there are obviously still a huge amount of VGM packs missing from SMS Power's database, and many problems (both discovered and not discovered) in the packs that are available.
Also thanks for the additional tutorials, you've contributed so much knowledge in these posts that will no doubt help a lot of people learn, although perhaps some aspects of your posts would be better moved to a dedicated "ripping tutorial" thread where they are more easily found by people looking for such information. Maxim would probably be best to advise on that aspect.
I'll delete my previous attachment so your pack with the updated tags will be the more noticeable pack