It is currently Sun Oct 22, 2017 5:38 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed Jan 23, 2013 3:48 am 
Offline

Joined: Tue Jan 31, 2006 5:43 am
Posts: 137
I have been thinking of using portable music history framework on a site that will handle console systems. After considering the availability of the complete romset vs rip availability vs bandwidth usage, I've come to the conclusion that it'd be best for now to stick with 8, 16 and some early 32-bit systems, as follows:

1983.07.15: NES/Famicom. Formats used: NSF+M3U, VGM.
1983.07.15: SG-1000. Formats used: SGC+M3U, KSS+M3U, VGM.
1985.10.20: Sega Master System/Sega Mark III. Formats used: same as SG-1000
1986.02.21: Famicom Disk System. Formats used: same as NES.
1987.10.30: TurboGrafx-16/PC Engine. Formats used: HES+M3U, VGM.
1988.12.04: TurboGrafx-CD/PC-Engine CD-ROMĖ›. Formats used: HES+M3U, VGM, Redbook Audio
1988.10.29: Sega Genesis/Sega Mega Drive. Formats used: VGM.
1989.11.30: SuperGrafx. Formats used: Same as TurboGrafx-16
1990.10.21: Super NES. Formats used: SPC, SNSF
1991.07.01: Neo Geo AES. Formats used: VGM
1991.12.12: Sega CD/Sega Mega-CD. Formats used: VGM, Redbook Audio
1993.09: Commodore Amiga CD32. Formats used: Amiga exotic formats, Redbook Audio.
1994.09.09: Neo Geo CD. Format used: Redbook Audio
1994.11.14: Sega 32X. Formats used: VGM
1994.12.23: PC-FX. Formats used: HES+M3U, Redbook Audio

The site should work exactly like portable music history does now, so a new release every x hours, in chronological order, with snesmusic.org frontend integration. All releases will be at least timed, with additional tags where possible. Basically pmh for consoles.

Now, I'm currently in the process of finalizing preliminary work and I should be able to start on producing actual releases soon, but the NES/Famicom portion has one major roadblock - lack of ripper credits. I'm not talking about the newer batch of rips, which are nicely documented both in this forums' "More NSF Requests" thread and on the rippers websites. But I'm having major problems crediting the older rips, those from Kevin Horton's nsf_pack.zip for instance, or rips made by Japanese people. While some of them have ripper credits on the NSFE archive, that's just a drop in the bucket comparing to... uh, 1500+ rips according to my calculations.

Can anyone here point me in the right direction with this one? Does a ripper credit list even exists? It would greatly speed up things on my part if I could not spend a few minutes per each game looking up the ripper everywhere.

Also, if anyone has questions or suggestions regarding the site as a whole, feel free to leave them here.


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 7:04 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
I see you have included one effectively second-generation console: SG-1000, which is equivalent in capability to the ColecoVision. In fact, they're so similar that one Coleclone plays both. Is there a reason you aren't including the other second-gen consoles (Atari 2600, Odyssey 2, Intellivision, Vectrex, and ColecoVision)? Is it that VCS and INTV games just didn't have much music? Or is it just that there aren't a lot of rips from those consoles?


Top
 Profile  
 
PostPosted: Wed Jan 23, 2013 7:34 am 
Offline

Joined: Tue Jan 31, 2006 5:43 am
Posts: 137
tepples wrote:
Is there a reason you aren't including the other second-gen consoles (Atari 2600, Odyssey 2, Intellivision, Vectrex, and ColecoVision)? Is it that VCS and INTV games just didn't have much music? Or is it just that there aren't a lot of rips from those consoles?


Combination of both, acually. There's not that many ColecoVision games ripped - even in Kevin Horton's SGC archive there are only a few rips, I believe. And while there's quite a number of VGM logs for Vectrex, most of them have only few seconds of sound effects. Not worth the effort, I say.
I thought about starting with Mark III for the Sega side, but since SG-1000 debuted on the same day as Famicom, I figured it wouldn't hurt to include it as well.

//EDIT: If anyone's interested in checking it, I uploaded a reference set here: http://www.sendspace.com/file/ug7ot9
The nsf+m3u should work in nezplug++, nsfplay and foo_gep, not sure about other players, the nsf+minim3u will work in nezplug++ and should work in nsfplay as well.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2013 6:54 pm 
Offline
User avatar

Joined: Fri Nov 06, 2009 9:01 pm
Posts: 8
I'm digging the nsf+minim3u setup. Having each track have its own m3u also makes it really, really easy to convert just one song to wav or mp3 straight out of Winamp without having to use another application.

My one thing I'd most like to see in addition to what's there (which admittedly I have no time to help do myself at the moment) is to have individual m3u's for the sound effects as well. And since not everyone would want sound effects included in the playlist for a game, maybe the best solution would then be to have two m3u's - one with sound effects and one without. That would be adding a lot of time and effort to the process, and some NSFs don't even have sound effects, but yeah... pipe dream completionist dream.

Also, if NSF2 is finalized, maybe any new NSFs that need to be created for this set should be made in that format. It would be a start towards upgrading, at the least.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2013 9:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
NSF2 isn't really finalized, though I'd venture I will implement it in NSFPlay within a year.

NSFe already has built-in playlists, and NSF2 should have the same. One might add a SFX playlist to NSFe (and NSF2), but I'm not sure there's much need to do that. NSF rips with SFX are relatively rare anyway, I think, and as you've notice m3u playlists can take care of people who want a customized playlist.

I eventually want to give NSFPlay a playlist editor and direct support for m3u playlists rather than having to rely on Winamp to do the job, but it's still a ways off.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2013 10:04 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
It'd be great if we stopped trying to have the file formats do things a common container could do. All we really need are system-specific formats which, per file, encode a single track (looping endlessly if it loops). Everything else can be done in a universal way: multiple tracks, metainformation, packaging into a single file.

And for system-specific formats, I've moved towards preferring logged formats. They're dead-simple recordings of all relevant sound chip writes that are very easy to play. It would be possible to make a very general logged format that worked for most systems, allowing reuse of most of the machinery to capture, write, read, and play files.

Logs can capture exactly what the actual game plays. Rips are never exactly like the game, because of slight timing differences, or unnoticed errors in ripping. They are also much more labor-intensive. Current rips can of course be automatically turned into logs, so they are still of value. If one can accept the slight accuracy loss of rips, then wherever it's less labor to make a rip and then record, that could be done rather than try to record the music of a game without sound effects.

Of course a third approach opens with logged formats, that of hacking the game just enough to where one can play and record each song. It need not be clean, just enough to get the songs playing without sound effects. Actually, if we were more pragmatic about or ripped formats, we could allow this kind of hack to pass as a game rip. This hypothetical "rip" format would just be a ROM along with some added code that gets it to play a music track. So what if it's large; it could be very much less labor-intensive to produce these "rips", and they would behave just like current rips (including being not fully accurate, since they wouldn't be running the game exactly as normal).


Top
 Profile  
 
PostPosted: Thu Jan 24, 2013 11:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
VGM already has 2A03, via the MAME/VS connection. It's lacking most of the Famicom expansions though, because of that same connection.

Personally, I'm kinda indifferent to the format details as long as it's got enough functionality to suit my purposes. My biggest problem with NSF is it has no track times, which NSFe solved nicely. I don't think NSF2 is terribly important-- it makes a couple of rips possible that can only be done in a very hacked way on NSF, and other than that it's mostly for homebrew devs that want to experiment with IRQs in their NSFs. Of course, a logged format like VGM already has track times, and has no problem logging music that would have required an IRQ.

My primary concern is just getting the sound accurate in the first place. The formats are adequate enough to me.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2013 11:44 pm 
Offline

Joined: Tue Jan 31, 2006 5:43 am
Posts: 137
klarthailerion wrote:
I'm digging the nsf+minim3u setup. Having each track have its own m3u also makes it really, really easy to convert just one song to wav or mp3 straight out of Winamp without having to use another application.


Yeah, that's what I personally use as well (for those very reasons).
But sadly, since it's not supported by foo_gep, which is widely used in the community, it's not really feasible to put files in this form on the site, so like pmh, the sets will just have a single m3u.

You can use this Python script to split them up manually: http://pastebin.com/RxYWrdMd

Just use split_m3u.py -g *.m3u or split_m3u.py -g -w *.m3u for WonderSwan rips.

klarthailerion wrote:
My one thing I'd most like to see in addition to what's there (which admittedly I have no time to help do myself at the moment) is to have individual m3u's for the sound effects as well.


No plans for that, sorry. I won't change the song number in the NSF header, so if there are SFX in the rip, you should be able to hear them just fine by loading the NSF, not the M3U(s) - you're free to modify the M3U to include them yourself, it's an open format. :)

blargg wrote:
And for system-specific formats, I've moved towards preferring logged formats. They're dead-simple recordings of all relevant sound chip writes that are very easy to play. It would be possible to make a very general logged format that worked for most systems, allowing reuse of most of the machinery to capture, write, read, and play files.


Other than VGM, which rainwarrior already mentioned, there was also another take on NSF logged format, I believe (or was that logged SID? I don't recall clearly). Didn't take off either way.
With well over 95% of the available games ripped to NSF already (seriously, from the No-Intro commercial games romset, I was left with 50-ish files out of 1500 without an existing NSF rip), I don't think things are going to change much regarding NES music format.
And I'm not planning on changing that - I just want to have them timed - if HVSC can do so for all of their 40000+ files, why shouldn't we?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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