NES sound logging... possible?

NES sound logging... possible?
by Tafoid on 2006-12-04 (#20098)

I originally posted this over at the Nestopia forum and was pointed here to post for discussion purposes.

Given the nature of NSF files, it's not that easy to make files which play individiual tracks contained within the full NSF files. NSFe allowes timing on tracks in an NSFe file, but this is a patch at best and the all tracks are still located in one file. There is a older utility "NSFTrackRipper" which splits NSF files into individual NSF files by tracks, but is limited in scope as to what it can handle and is far from an optimal solution.

What I was wondering: Is or has there been any interest in making a Nintendo Sound Logger? VGM is a popular logged-file format with the freedom of creating individual files for each track. Sadly, it's focused primarily on the Sega side of things currently. I'm fairly sure a NES compatable .VGM logged file would be accepted by many people.

What it would take, I'd assume, is someone with the abilities to step up and create a NES logged format. Also, use current technologies (eg. VGM or other NSF players) to allow the playback of this logged information. A converter, too, would be the best to transfer the current NSF files to a new NES logged format.

Comments?

Tafoid

by Quietust on 2006-12-04 (#20099)

There was a logged format for the NES, called "NESA". It was obsoleted by NSF, since logged sound formats are inherently inferior due to their lack of looping support and their increased size.

by Memblers on 2006-12-04 (#20100)

There already was a logged format created before NSF, called NESA.

I see only one advantage to a logged format, and that is that nearly any computer could play it since there is no CPU to emulate (even another non-6502 8-bit machine could do it). But the logged data is freaking huge, so it needs to be compressed.

Is there some other reason a logged format would be useful for that I've overlooked?

I think it's pretty strange how popular VGM format is with SMS (besides the fact that it has momentum from people using it so much). With some games people have to go to crazy lengths hacking the game so they can log the music without interruptions.. that's really more work than just locating the sound engine and getting every song and sfx in one go (including hidden ones that the game might never play).

I'm not sure what that NSFTrackRipper program does, but if it's just having a certain song in one file that you want, it's as easy as changing one byte in the NSF header (the starting song #, maybe the maximum number if you don't want it to go on to the next track automatically).

by tepples on 2006-12-04 (#20101)

Perhaps we need to go down the path of PSF. Treat the .nsf or .nsfe file as if it were an "nsflib", and then have .mininsf that references (possibly part of) one NSF song.

by ugetab on 2006-12-04 (#20103)

You don't really need to extend the format very far. A 'mininsf' file could be programmed to reference a flat-out NSF file. The distinction is that there would only be 1 byte of data(the song number) that would have any bearing on the song played, and the rest could be tagging information. If programmed correctly, the file may only need to consist of text, and reference a Song tag for the song number to play. Such a system would be easy to use for auto-generated mininsf files, and the original format wouldn't need to change, because it would just be an extension of the format, layered on top of the NSF format.

by commodorejohn on 2006-12-04 (#20104)

The problem I see with the idea of a miniNSF format is that NSFs are already about as "mini" as they will ever need to be. The big reason for miniPSF's existence, as I see it, is so that instruments from individual files can be shared across an entire game soundtrack; on sample-based consoles, this is obviously a significant space reduction. But NSF doesn't have full-length samples anyway; the largest possible DMC sound is 16KB in length, and anything that long would most likely not be shared anyway.

by blargg on 2006-12-05 (#20106)

Just to throw my two cents in (I was thinking of this thread just now and had a strong opinion on the matter, so I figured I'd post it).

There's no need for a standard format for logged NES music since logs can be extracted from an NSF file, and playback is not at all processor-intensive. In a sense an NSF file already contains all the sound data, but in a highly compressed form. If you have a specialized application that needs logged data, modify one of the several open-source NSF players to log data you need. The format is can be whatever works for you, since there's no benefit gained by using a standard format.

The same goes for any other logged formats which have been superseded by ripped formats. For example I've recently come into possession of many Sega Master System rips in KSS format, making the previous VGM logs obsolete.

by Memblers on 2006-12-05 (#20107)

That actually reminds me too, blargg and I have both used logged formats. We've both modified NSF players to send logged data through the serial port (rather than saving it) to the NES's controller port to be played (or streamed) on NES.

So there's an example of a specialized application for it, kinda cool too, though my way was impossible to use DPCM with. Probably not what Tafoid has in mind though, heheh.

by Tafoid on 2006-12-05 (#20114)

Myself, I am open to any options as to how to produce and handle NES sound. Logging, while producing larger files for the same gain as NSF's, are still MUCH better than WAV or even MP3's as far as consumed storage. The advantages stated before of portability to other devices, too, are important.

OPTIONS is all I'm looking for - Options that a normal end-user can employ to create/manipulate/transfer NES Sound. A majority of end-users lack specific ASM knowledge or C programming skills to accomplish these tasks on thier own. I guess my plea comes mostly from my inability currently to rip my own NSF's or code up my own solutions with the given sources.

I'm not certain how it is with NES Sound Data, but there are many games for the Super Nintendo which are unable to be saved via the normal SPC Dumps. In this case, logging of the games would be a viable alternative.

I am also not opposed to a PSF-type approach either, anything that will allow me an unfettered access to a certain track immediately without editing NSF headers or modifying game code is a plus! We cannot forget loop points, timings and even fading - all important.

Thanks for your input, everyone!
Tafoid

by Knurek on 2006-12-05 (#20116)

Tafoid wrote:
OPTIONS is all I'm looking for - Options that a normal end-user can employ to create/manipulate/transfer NES Sound.

Interestingly enough, there's already a format that enables both tag data, track selection, timing and all that other glut. It's even supported by one of the best NSF players (NSFPlug), though adding support to other players should be fairly trivial (both NSFPlug and NEZPlug from which the format originates are open source).

I'm talking about extended M3U. And really, talking about mininsf or other similar format when that's available is kinda pointless, you know?

by Bregalad on 2006-12-05 (#20117)

One advantage I could see on logged format is that it would allow to replay sound effects that would be very hard to impossible to dump in function on how the sound driver handles them.

by tokumaru on 2006-12-05 (#20119)

Wouldn't logged sound also allow rewinding or random access to any point in the track?

I don't know much about NES music, but is it really possible to make NSF's of any game? Aren't there any games that use some weird routines to play their music that doesn't fit the scheme used in NSF's?

The nice thing about NSF's is that they can be inserted back into NES programs/games and all, but I guess that logged sound is best for playback only (in some sort of audio player, not a game system).

by commodorejohn on 2006-12-05 (#20120)

I'm not aware of anything that would make an NSF undumpable unless the music changed in response to the game state. The reason some SNES games are undumpable is that they update the music via the 65816, which the SPC format doesn't emulate.

by Bregalad on 2006-12-05 (#20123)

tokumaru wrote:
I don't know much about NES music, but is it really possible to make NSF's of any game? Aren't there any games that use some weird routines to play their music that doesn't fit the scheme used in NSF's?

Well, I really cannot find any. The worst thing that comes to mind would be merge some sound routines with some totally unrelated routines, wich no programmer would want to do anyway. The routine that would have nothing to do with sound could be "hidden" somewhere in the sound playback routine and freze the code if you don't run it with the complete game engine, wich is the case of NSF players. That would fit the NSF format by replacing a call by NOPs, but it would give a very very hard time to the NSF ripper.
Also, some code that would wait for a DPCM IRQ that would be triggered by not-sound code or a sound code that relies on mapper registers to run would be pretty bad. I know Low-G-Man relies on open bus at $6000-$7fff, and Just Breed relies on the MMC5 multiplier at $5205-$5206. Without those, both sound codes will crash.
Finally there is Battletoads with its infamous PCM playback (only on title screen, winning music and stage-advance-custcene music). I think it worked pretty well without the PCM playback, but it simply won't fit the NSF format with the PCM playback unless Quietust updated it (and only Nintendulator support it yet anyway...)

Quote:
The reason some SNES games are undumpable is that they update the music via the 65816, which the SPC format doesn't emulate.

Well, the music can only be updated by the SPC700 code techinically, but some games have SPC700 playback codes that relies on communication with the 65C816 CPU to run. Most playback codes only communicate on song change and to play sound effects. Some games also have SPC dumps that doesn't work for some obscure reason, but that people have managed to get working on the SPC format (Terranigma, Fire Emblem 4 and 5, Super Famicom Wars and Rudra no Hihou comes in mind). Eventually, there is Tales of Phantasia and Star Ocean were the SPC run pretty well on its own, but have trouble playing some instruments and of course voice playback where the main CPU constantly communicates with the SPC700 to refresh sample data in a double-buffered algorithm.

by Quietust on 2006-12-05 (#20124)

commodorejohn wrote:
The reason some SNES games are undumpable is that they update the music via the 65816, which the SPC format doesn't emulate.

The solution, of course, is to make an SNES equivalent of NSF which does not simply take a RAM snapshot of the SPC700. Sure, it'd be a bit more difficult to do (would require actual effort above just playing through the game) and would require a slightly beefier player (would have to emulate the 65816 as well as the SPC700), but they would be radically smaller - as it is, most SPC soundtracks are larger than the original game's ROM image!

Don't even get me started on Sega Genesis/Megadrive music logs - once the raw PCM is added, one song exceeds the size of the entire game...

by Knurek on 2006-12-05 (#20125)

Quietust wrote:
but they would be radically smaller - as it is, most SPC soundtracks are larger than the original game's ROM image!

Hence the RSN archives.

by Bregalad on 2006-12-05 (#20126)

RSN archives are just SPC files all put in a RAR archive that was renamed RSN. So if the SPC files contains multiple sample data, code, etc..., they are just compressed and not reducted to only one data. I don't know if the RAR algorithm will automatically detect large chunks of data that are repeated to compress the files.

by Knurek on 2006-12-05 (#20127)

Bregalad wrote:
RSN archives are just SPC files all put in a RAR archive that was renamed RSN. So if the SPC files contains multiple sample data, code, etc..., they are just compressed and not reducted to only one data. I don't know if the RAR algorithm will automatically detect large chunks of data that are repeated to compress the files.

Like I said - hence RSN. They use solid compression almost exclusively (well, any sane ones do), so yeah, repeated samples are taken care of. Unless of course a SNES game would use more than 4 MB of sample data, that's the limit of RAR dictionary size. But that didn't happen anywhere, did it?

by blargg on 2006-12-05 (#20129)

Tafoid wrote:
Logging, while producing larger files for the same gain as NSF's, are still MUCH better than WAV or even MP3's as far as consumed storage. The advantages stated before of portability to other devices, too, are important.

It sounds like you're arguing for a standardized NES logged sound format. NSF is even smaller, so logged doesn't win in size. A logged format still requires a specialized player. If you want portability, mp3 is the ticket.

Quote:
Options that a normal end-user can employ to create/manipulate/transfer NES Sound. A majority of end-users lack specific ASM knowledge or C programming skills to accomplish these tasks on thier own. I guess my plea comes mostly from my inability currently to rip my own NSF's or code up my own solutions with the given sources.

Where are these masses who want to make logged NES sound files? Is it due to the obscure NES games that haven't been ripped to NSF yet? An interesting idea to handle that would be to turn a NES emulator into a standalone music player that starts a "track" using a ROM + save state.

Quote:
anything that will allow me an unfettered access to a certain track immediately without editing NSF headers or modifying game code is a plus! We cannot forget loop points, timings and even fading - all important.

Use an NSF player library, load NSF, then start whatever track you want. I'm still not understanding what you ultimately want to accomplish here. You're talking ways of doing it, but not what the overall purpose is.

tokumaru wrote:
Wouldn't logged sound also allow rewinding or random access to any point in the track?

All sound formats allow this; it's just a question of how quickly you can seek. Considering that a decent NSF player should run at least 100-200x real-time on a modern PC, seeking anywhere in a track is a non-issue.

Bregalad wrote:
Finally there is Battletoads with its infamous PCM playback (only on title screen, winning music and stage-advance-custcene music). I think it worked pretty well without the PCM playback, but it simply won't fit the NSF format with the PCM playback unless Quietust updated it (and only Nintendulator support it yet anyway...)

When I release an updated Game_Music_Emu in a week or so, it will have support for the current PCM NSF rips. That means that Audacious Media Player, Audio Overload, foo_gep, and Game Music Box will support it on their next update.

Quietust wrote:
Don't even get me started on Sega Genesis/Megadrive music logs - once the raw PCM is added, one song exceeds the size of the entire game...

Not since late last November when I worked with Maxim to add a common PCM data bank to the VGM format, which Project 2612 has been using since.

Knurek wrote:
They use solid compression almost exclusively (well, any sane ones do), so yeah, repeated samples are taken care of.

And if someone doesn't like the proprietary compression algorithm, they could use 7-zip compression or a free replacement I developed for SPC soundtracks that achieves close to what RAR does.

by 85cocoa on 2006-12-05 (#20131)

Not perfectly on topic, but has there ever been a format (either ripped or logged) for music from MSX games?

by tepples on 2006-12-05 (#20132)

blargg wrote:
Considering that a decent NSF player should run at least 100-200x real-time on a modern PC, seeking anywhere in a track is a non-issue.

I don't always listen to music on a modern PC. Usually I'm on the bus, carrying what is essentially a gaming PDA with 4 MB of RAM and a 67 MHz ARM CPU.

by kingshriek on 2006-12-05 (#20133)

85cocoa wrote:
Not perfectly on topic, but has there ever been a format (either ripped or logged) for music from MSX games?

KSS, a rip format.

by blargg on 2006-12-05 (#20134)

85cocoa wrote:
has there ever been a format (either ripped or logged) for music from MSX games?

Yes: KSS. It also supports Sega Master System rips.

tepples wrote:
I don't always listen to music on a modern PC. Usually I'm on the bus, carrying what is essentially a gaming PDA with 4 MB of RAM and a 67 MHz ARM CPU.

And you need to do a lot of seeking within tracks while riding the bus?

by tepples on 2006-12-05 (#20135)

My PC is also not modern (0.866 GHz PIII). Seeking in PSFs is nearly unbearable.

by baisoku on 2006-12-06 (#20136)

tepples wrote:
I don't always listen to music on a modern PC. Usually I'm on the bus, carrying what is essentially a gaming PDA with 4 MB of RAM and a 67 MHz ARM CPU.

Then i'd argue you hardly have the room for a logged format.
As far as throwing my 2 cents into the fountain, i say that you can generate a logged version of game music from an NSF, but you can't go the other way around. Which obviates the need for a new format.

by blargg on 2006-12-06 (#20137)

Quote:
My PC is also not modern (0.866 GHz PIII). Seeking in PSFs is nearly unbearable.

And the relevance of this to a logged NES sound format is???

by Zepper on 2006-12-06 (#20141)

*blinks* *blinks* Kevin Horton's Castlevania 3 logs... *blinks*
Do you remember of this? Of that player?

by Quietust on 2006-12-06 (#20143)

The only logged data I remember kevtris making was for the VRC7, back when it wasn't understood very well, and a VRC6 emulator written in QBASIC. Both of those took plaintext-based logfiles instead of a binary format, though, and I think CopyNES knows how to play both of them, but that's really about it.