Forums

This is probably one of the more challenging packs I've worked on. I have yet to encounter one that is entirely smooth sailing. Up until the penultimate track (now 07), lpfnd worked well, far better than usual actually. I almost missed the fact lp2fnd was wrong on this one, because matches were 100k+ lines. I've had this happen before so I was prepared a bit. I ended up converting to midi, which did not help, even after I disabled all the channels but one..there was still so much going on, it was hard to find the right loop point, though easy to spot by ear. The composer Neil Baldwin (a prolific western composer in the tradition of c64 composers like Rob Hubbard) packs alot of information into each voice. So there's more going on than just a melody if you look closely. Ultimately, I isolated the top voice and used several wave viewing programs to confirm that indeed..there is alot going on, and it's not just conversion errors. I was able to get my loop points after disecting the files to the sample level. Something I have not had to do for a while now.

What actually took the MOST time, by far, was tagging this properly. Usually the possibility of consulting external sources for japanese titles and the like/who composed what isn't available, but in this case it was.
I ended up using youtube to compare the different versions, and see if I was missing anything. Neil seems to have composed everything based on some scores and alot of transcription, plus his own ideas and application based on hardware limitations.

You can read about this game (nes version, same composer) at http://dutycyclegenerator.com/ (his site) and http://www.originalsoundversion.com/?p=5559 (interview).

Fascinating stuff. Worth the trouble to dump this for that alone. Feel free to email him if you like, he supports chiptune afficionados.

Exhausting the resources available to tag this properly took longer than the encoding process itself, which was fairly straightforward.

This game has an on/off trigger at C0d8. By default it is 0x0F. Setting it to anything above, it resets to 0x0f, but anything less, and it gets set to 0x00. Sound off. Memory trigger at c0db. Songs are values 0x00 to 0x12 using only even values. Odd values produce strange results. The GG version uses the same code etc. Even the 1994 version (year later) does not fix the unused track issue or silence in level 3 (if it was not intended).

This pack has the same issue as my other recently released pack , and possibly also Ace of Aces (50hz pack recorded at 60hz). Once I find the standard solution I will apply it, though I believe the packs probably meet the guidelines pretty well (just set playback to 50hz in your vgmplayers) I don't like that solution, since I really don't use the up to date players anyway unless I have to.

Anyway. Enjoy.

http://www.smspower.org/Music/JungleBook-SMS

I almost didn't do it. The idea of redoing work I had already done seemed so distasteful I kept putting it off until there was nothing else in the queue.

Ended up being quite enjoyable and painless. I was much more careful about how I logged the tracks, and got much better results. I couldn't remember anything when I started, but logging helped jar my memory, as well as the track notes.

Interestingly,

I didn't actually log time, but redoing everything felt as if it took less time than tagging (and then retagging) MK II. To be fair, the bulk of this work was completed, so all I did was update the tags first, then trimmed.
Originally was only going to do one track, but it ended up being so easy and different from my usual process that I finished in a jiffy, in good spirits.

Still based on SMS version. No ambiguity with console differences, now at 50 Hz.

Extras were edited slightly.
this is the version to post. I will delete the attachments from the first post after a grace period. In case anyone wants to compare a bad log to a good one.

Also interesting, why do the vgms in zip files need to be gzippped beforehand. My uncompressed was 1kb smaller than the precompressed version, making any advantage dubious by today's standards.

Having two standards adds a bit of overhead. I now keep two of the same sets, and needing to update anything vgm/tag related means alot of extra steps to process the uncompressed and compressed vgms.

Not to mention, compressed vgms will not convert in vgm2mid (use the vgm7z as your source, it will work). Has anyone discussed retiring that standard? Of course this is an isolated case, but the issue of overhead is not an ideal use of time to save at most a few kb (probably not even that) in an age where even phones have fast internet connection.

Also...vgmify is evil. I tested it to put a check on my grousing, and it deleted everything but the extras! In this case..good thing I kept a backup...I almost didn't...I forgot to include pngout but 7za (commandline) is in the system path, so not sure what happened, or if it outputs to some mystery directory.

But all's well that ends well.

[Attachments removed]

People will download a pack and extract it, usually. Zip files should extract in the optimal (compressed) form. VGM7z is designed to be as small a file as possible for the same result. To achieve that, the contents should be uncompressed, then compressed when extracted. in_vgm does this.

The benefit of VGM7z is minor for 8-bit music but makes a huge difference for Mega Drive music, and maybe other chips with lots of samples. However it never really took off and I'm considering giving up on it.

Regarding compressed vs uncompressed support in tools, that should never have been an issue but we made a bad decision at the start, namely to make compression change the filename - vgz = compressed VGM. The correction is to say that VGM files can be compressed so every tool must support it, and users should not have to care.

vgmify can be destructive, it works for me but you shouldn't use it blind. I wish there was a decent GUI pack creator that would take a bunch of files, let you see the tags in a grid, bulk edit them, catch common errors, generate the txt, optimise and compress... but I guess I need to do it myself.

I'm not entirely clear why you re-did this pack sherpa, could you elaborate for me?

Was it just to correct the speed?

Even if it's just that, it's nice to have it in the speed I remember so thanks for doing it. Sometimes I think it would be nice to have all my SMS VGM packs in 50hz (even if they were intended to be 60hz) just because that's how I remember them sounding.

And by the way I know I've still got a PM of yours to reply to, haven't got around to it yet

Well, actually there is a tool. I just forgot about it. vgmtoolbox supports batch tagging. Despite its name, tagging seems to be all it supports for vgms, most of its features are around other vgm type formats including nsf and stream based. It's actually the first thing I found when I was looking for vgmtool r5. I was very confused because what I saw did not match the tutorials. It also doesn't seem to compress the vgm, which is a plus. vgmtool r5 does-I wish it didn't.

So one headache will be ameliorated. As far as I know vgm_tag does not support batch processing unless you create a batch entry for each file. I tried tagging *.vgm and it returned an error. So now I am only missing batch compression/uncompression...is there a utility that can do this? Is it jsut a matter of placing gzip in the path and running a command? If it allows * compression like 7z command line does, it might make things easier. Everything would probably have an odd extension, but I could easily rename them. I have to do that every time I use vgmtool anyway.

That's what really takes alot of time. Dragging and tagging each file individually and then after everything is finished, manually (at least it's not command line, or browse only) uncompress every file for vgm7z.

I don't mind vgm7z...it's convenient for playing all the files in one archive. Plus since I now know it's uncompressed, it will be my source if I ever want to midi convert one of the released packs. I came to vgm since I was transcribing everything by ear, and the ability to compare an accurate machine conversion to my efforts was too alluring to overlook. I've since fallen off the wagon a bit in that regard, and it's been a while since I've actually analyzed in detail anything I've logged or tried to transcribe a tune.

A while ago on irc, someone was complaining about how vgms were all single files and you couldn't organize the tracks you wanted in one file like the machine based formats (gbs/nsf/hes etc) . Wish I would have remembered vgm7z...but I still wasn't familiar with all the details. (still learning). But yeah, the only place I see vgm7z is on smspower. Where it's least useful (the files are so small already).

Thanks for pointing out the issue with compresion of samples. That did not occur to me...(not really relevant here). Still, if it weren't for all the work you guys did here, those other sites might not exist.

TheAssassin:

You beat me by a bit. Well technically this pack is incorrect. It can be fixed by editing the timer waits and other complicated things or by changing the playback rate in the header and playing back in vg_play (possibly in_vgm as well, but I don't use winamp).

So you could do that for any file in 60 hz..

If you have vgmplay, edit the .ini file setting where it says

PlaybackRate = 0

to
PlaybackRate = 50

The baddly logged jungle book sounds the same as the good one. I haven't played around much, but it could be that if you hexedi byte 0x24 and change it from 3C (60) to 50 it might have a similar effect. That might be wrong. I'm having trouble with the math in my head.

But you can get it the way you like, probably with little effort. Getting it to sound exactly like the pal might take a bit of legwork, finding what the right setting is in each situation.

Maybe one of the more knowledgable folks can clarify.

I think 0x24 is for when you log it wrong, and you're supposed to put 50 or 60 (as if it were decimal) rather than changing 3C to 32 (50 in hex). I think when I played around with it, I actualy set it to 72 (48 in hex) to get the right slowdown, but that's not how it's supposed to work, plus my tests were with improperly logged files so results will vary..

I think changing the playback setting in the ini is the way to go for starters. Don't forget to set it back to 0 when you're done if you want a 50 hz to sound like 50 hz and a 60 like 60...

Though tecnically, excepting some cases your pal version should sound like the ntsc unless the programmers did not compensate for the region difference in timing the music. Does happen from time to time.

Sorry sherpa, you've lost me! I don't understand barely anything you wrote there lol.

Could you explain in less technical terms what exactly is incorrect about the pack? I'm playing the pack and it sounds fine to me, I can't hear anything wrong with it. Everything sounds the same as when I played the game on my PAL system all those years ago.

I'm talking about the one I haven't deleted from over a week ago.

The one I encoded at 60hz , but was a 50hz game.

The latest one is correct. 50Hz will play back at 50 Hz with the default settings.

What I was talking about was, for example game X...ripped at 60hz..which for you sounds fast. Whether there is an original at 50hz or not, you can change the playback settings in vgmplay and listen to it slower, which is what you said you wanted in your post.

In other words you are not trapped by the encoding, you just need to use a player that supports the playback setting in the header/one that lets you change it globally like vgm_play.

I was talking about your concern, not the pack in this thread. I only mentioned it as a "for example". So for example...if there were no 50hz Tom and Jerry the movie pack. You were stuck with the gg version which to you is fast. You can take that gg version and play it back as if it were 50hz by chaning one line in the ini file.

That extra stuff was purist verbiage, since it might not be "exactly" the same. There are several variables that go into file playback and I'm not clear how they all fit. But a purist could go and make them the same if they were'nt for some reason. Might take a combination of procedures. Though I doubt the ear would be able to tell much difference between a pure version at 50hz and one set up to play that way.

You have options. That's all I'm saying. You're not stuck listening to 50hz tunes play 120% what you remember. I'd be surprised if it happened that often though. Probably not rare, but I doubt it's the usual fare.

Ah I see, thanks for the clarification. I like to use winamp to listen to my VGMs (using the plugin InVGM) does anyone happen to know if there's a way to get winamp to play a 60hz VGM pack at 50hz?

One of the reasons I like winamp is it's so easy to convert files to wav using the disk writer function, as I use wavs with my portable music player.

It's in the options.

Ah I've found it now, just have to click configure on the inVGM plugin, thanks

Author	Message
sherpa Joined: 28 Nov 2014 Posts: 365	[VGM Pack] The Jungle Book (SMS) Posted: Mon Jan 12, 2015 8:26 am Last edited by sherpa on Mon Feb 23, 2015 4:29 pm; edited 2 times in total
sherpa Joined: 28 Nov 2014 Posts: 365	This is probably one of the more challenging packs I've worked on. I have yet to encounter one that is entirely smooth sailing. Up until the penultimate track (now 07), lpfnd worked well, far better than usual actually. I almost missed the fact lp2fnd was wrong on this one, because matches were 100k+ lines. I've had this happen before so I was prepared a bit. I ended up converting to midi, which did not help, even after I disabled all the channels but one..there was still so much going on, it was hard to find the right loop point, though easy to spot by ear. The composer Neil Baldwin (a prolific western composer in the tradition of c64 composers like Rob Hubbard) packs alot of information into each voice. So there's more going on than just a melody if you look closely. Ultimately, I isolated the top voice and used several wave viewing programs to confirm that indeed..there is alot going on, and it's not just conversion errors. I was able to get my loop points after disecting the files to the sample level. Something I have not had to do for a while now. What actually took the MOST time, by far, was tagging this properly. Usually the possibility of consulting external sources for japanese titles and the like/who composed what isn't available, but in this case it was. I ended up using youtube to compare the different versions, and see if I was missing anything. Neil seems to have composed everything based on some scores and alot of transcription, plus his own ideas and application based on hardware limitations. You can read about this game (nes version, same composer) at http://dutycyclegenerator.com/ (his site) and http://www.originalsoundversion.com/?p=5559 (interview). Fascinating stuff. Worth the trouble to dump this for that alone. Feel free to email him if you like, he supports chiptune afficionados. Exhausting the resources available to tag this properly took longer than the encoding process itself, which was fairly straightforward. This game has an on/off trigger at C0d8. By default it is 0x0F. Setting it to anything above, it resets to 0x0f, but anything less, and it gets set to 0x00. Sound off. Memory trigger at c0db. Songs are values 0x00 to 0x12 using only even values. Odd values produce strange results. The GG version uses the same code etc. Even the 1994 version (year later) does not fix the unused track issue or silence in level 3 (if it was not intended). This pack has the same issue as my other recently released pack , and possibly also Ace of Aces (50hz pack recorded at 60hz). Once I find the standard solution I will apply it, though I believe the packs probably meet the guidelines pretty well (just set playback to 50hz in your vgmplayers) I don't like that solution, since I really don't use the up to date players anyway unless I have to. Anyway. Enjoy. http://www.smspower.org/Music/JungleBook-SMS

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 23, 2015 5:50 am Last edited by sherpa on Mon Feb 23, 2015 4:30 pm; edited 1 time in total
sherpa Joined: 28 Nov 2014 Posts: 365	I almost didn't do it. The idea of redoing work I had already done seemed so distasteful I kept putting it off until there was nothing else in the queue. Ended up being quite enjoyable and painless. I was much more careful about how I logged the tracks, and got much better results. I couldn't remember anything when I started, but logging helped jar my memory, as well as the track notes. Interestingly, I didn't actually log time, but redoing everything felt as if it took less time than tagging (and then retagging) MK II. To be fair, the bulk of this work was completed, so all I did was update the tags first, then trimmed. Originally was only going to do one track, but it ended up being so easy and different from my usual process that I finished in a jiffy, in good spirits. Still based on SMS version. No ambiguity with console differences, now at 50 Hz. Extras were edited slightly. this is the version to post. I will delete the attachments from the first post after a grace period. In case anyone wants to compare a bad log to a good one. Also interesting, why do the vgms in zip files need to be gzippped beforehand. My uncompressed was 1kb smaller than the precompressed version, making any advantage dubious by today's standards. Having two standards adds a bit of overhead. I now keep two of the same sets, and needing to update anything vgm/tag related means alot of extra steps to process the uncompressed and compressed vgms. Not to mention, compressed vgms will not convert in vgm2mid (use the vgm7z as your source, it will work). Has anyone discussed retiring that standard? Of course this is an isolated case, but the issue of overhead is not an ideal use of time to save at most a few kb (probably not even that) in an age where even phones have fast internet connection. Also...vgmify is evil. I tested it to put a check on my grousing, and it deleted everything but the extras! In this case..good thing I kept a backup...I almost didn't...I forgot to include pngout but 7za (commandline) is in the system path, so not sure what happened, or if it outputs to some mystery directory. But all's well that ends well. [Attachments removed]

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Fri Jan 23, 2015 9:03 am
	People will download a pack and extract it, usually. Zip files should extract in the optimal (compressed) form. VGM7z is designed to be as small a file as possible for the same result. To achieve that, the contents should be uncompressed, then compressed when extracted. in_vgm does this. The benefit of VGM7z is minor for 8-bit music but makes a huge difference for Mega Drive music, and maybe other chips with lots of samples. However it never really took off and I'm considering giving up on it. Regarding compressed vs uncompressed support in tools, that should never have been an issue but we made a bad decision at the start, namely to make compression change the filename - vgz = compressed VGM. The correction is to say that VGM files can be compressed so every tool must support it, and users should not have to care. vgmify can be destructive, it works for me but you shouldn't use it blind. I wish there was a decent GUI pack creator that would take a bunch of files, let you see the tags in a grid, bulk edit them, catch common errors, generate the txt, optimise and compress... but I guess I need to do it myself.

TheAssassin Joined: 06 Jan 2005 Posts: 177	Posted: Fri Jan 23, 2015 4:23 pm
TheAssassin Joined: 06 Jan 2005 Posts: 177	I'm not entirely clear why you re-did this pack sherpa, could you elaborate for me? Was it just to correct the speed? Even if it's just that, it's nice to have it in the speed I remember so thanks for doing it. Sometimes I think it would be nice to have all my SMS VGM packs in 50hz (even if they were intended to be 60hz) just because that's how I remember them sounding. And by the way I know I've still got a PM of yours to reply to, haven't got around to it yet

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 23, 2015 5:00 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Well, actually there is a tool. I just forgot about it. vgmtoolbox supports batch tagging. Despite its name, tagging seems to be all it supports for vgms, most of its features are around other vgm type formats including nsf and stream based. It's actually the first thing I found when I was looking for vgmtool r5. I was very confused because what I saw did not match the tutorials. It also doesn't seem to compress the vgm, which is a plus. vgmtool r5 does-I wish it didn't. So one headache will be ameliorated. As far as I know vgm_tag does not support batch processing unless you create a batch entry for each file. I tried tagging .vgm and it returned an error. So now I am only missing batch compression/uncompression...is there a utility that can do this? Is it jsut a matter of placing gzip in the path and running a command? If it allows compression like 7z command line does, it might make things easier. Everything would probably have an odd extension, but I could easily rename them. I have to do that every time I use vgmtool anyway. That's what really takes alot of time. Dragging and tagging each file individually and then after everything is finished, manually (at least it's not command line, or browse only) uncompress every file for vgm7z. I don't mind vgm7z...it's convenient for playing all the files in one archive. Plus since I now know it's uncompressed, it will be my source if I ever want to midi convert one of the released packs. I came to vgm since I was transcribing everything by ear, and the ability to compare an accurate machine conversion to my efforts was too alluring to overlook. I've since fallen off the wagon a bit in that regard, and it's been a while since I've actually analyzed in detail anything I've logged or tried to transcribe a tune. A while ago on irc, someone was complaining about how vgms were all single files and you couldn't organize the tracks you wanted in one file like the machine based formats (gbs/nsf/hes etc) . Wish I would have remembered vgm7z...but I still wasn't familiar with all the details. (still learning). But yeah, the only place I see vgm7z is on smspower. Where it's least useful (the files are so small already). Thanks for pointing out the issue with compresion of samples. That did not occur to me...(not really relevant here). Still, if it weren't for all the work you guys did here, those other sites might not exist.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 23, 2015 5:34 pm
sherpa Joined: 28 Nov 2014 Posts: 365	TheAssassin: You beat me by a bit. Well technically this pack is incorrect. It can be fixed by editing the timer waits and other complicated things or by changing the playback rate in the header and playing back in vg_play (possibly in_vgm as well, but I don't use winamp). So you could do that for any file in 60 hz.. If you have vgmplay, edit the .ini file setting where it says PlaybackRate = 0 to PlaybackRate = 50 The baddly logged jungle book sounds the same as the good one. I haven't played around much, but it could be that if you hexedi byte 0x24 and change it from 3C (60) to 50 it might have a similar effect. That might be wrong. I'm having trouble with the math in my head. But you can get it the way you like, probably with little effort. Getting it to sound exactly like the pal might take a bit of legwork, finding what the right setting is in each situation. Maybe one of the more knowledgable folks can clarify. I think 0x24 is for when you log it wrong, and you're supposed to put 50 or 60 (as if it were decimal) rather than changing 3C to 32 (50 in hex). I think when I played around with it, I actualy set it to 72 (48 in hex) to get the right slowdown, but that's not how it's supposed to work, plus my tests were with improperly logged files so results will vary.. I think changing the playback setting in the ini is the way to go for starters. Don't forget to set it back to 0 when you're done if you want a 50 hz to sound like 50 hz and a 60 like 60... Though tecnically, excepting some cases your pal version should sound like the ntsc unless the programmers did not compensate for the region difference in timing the music. Does happen from time to time.

TheAssassin Joined: 06 Jan 2005 Posts: 177	Posted: Fri Jan 23, 2015 5:59 pm
TheAssassin Joined: 06 Jan 2005 Posts: 177	Sorry sherpa, you've lost me! I don't understand barely anything you wrote there lol. Could you explain in less technical terms what exactly is incorrect about the pack? I'm playing the pack and it sounds fine to me, I can't hear anything wrong with it. Everything sounds the same as when I played the game on my PAL system all those years ago.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 23, 2015 7:11 pm
sherpa Joined: 28 Nov 2014 Posts: 365	I'm talking about the one I haven't deleted from over a week ago. The one I encoded at 60hz , but was a 50hz game. The latest one is correct. 50Hz will play back at 50 Hz with the default settings. What I was talking about was, for example game X...ripped at 60hz..which for you sounds fast. Whether there is an original at 50hz or not, you can change the playback settings in vgmplay and listen to it slower, which is what you said you wanted in your post. In other words you are not trapped by the encoding, you just need to use a player that supports the playback setting in the header/one that lets you change it globally like vgm_play. I was talking about your concern, not the pack in this thread. I only mentioned it as a "for example". So for example...if there were no 50hz Tom and Jerry the movie pack. You were stuck with the gg version which to you is fast. You can take that gg version and play it back as if it were 50hz by chaning one line in the ini file. That extra stuff was purist verbiage, since it might not be "exactly" the same. There are several variables that go into file playback and I'm not clear how they all fit. But a purist could go and make them the same if they were'nt for some reason. Might take a combination of procedures. Though I doubt the ear would be able to tell much difference between a pure version at 50hz and one set up to play that way. You have options. That's all I'm saying. You're not stuck listening to 50hz tunes play 120% what you remember. I'd be surprised if it happened that often though. Probably not rare, but I doubt it's the usual fare.

TheAssassin Joined: 06 Jan 2005 Posts: 177	Posted: Fri Jan 23, 2015 8:36 pm
TheAssassin Joined: 06 Jan 2005 Posts: 177	Ah I see, thanks for the clarification. I like to use winamp to listen to my VGMs (using the plugin InVGM) does anyone happen to know if there's a way to get winamp to play a 60hz VGM pack at 50hz? One of the reasons I like winamp is it's so easy to convert files to wav using the disk writer function, as I use wavs with my portable music player.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Fri Jan 23, 2015 8:54 pm
	It's in the options.

TheAssassin Joined: 06 Jan 2005 Posts: 177	Posted: Fri Jan 23, 2015 9:16 pm
TheAssassin Joined: 06 Jan 2005 Posts: 177	Ah I've found it now, just have to click configure on the inVGM plugin, thanks

Forums

View topic - [VGM Pack] The Jungle Book (SMS)