What's new
  • Most issues reported these days stem from users not enabling their emulators to use the required amount of RAM.
    We also tend not to use the search feature but post our issues within the texture pack release page.
    Failure to load a texture pack should not be posted in the release thread unless you have already patched the emulator.

    If you don't have the resources to use Large/HD texture packs please do not attempt to do so.
    Users should have a minimum amount of System RAM not less then 4GB's.
    If you have less then 4GB's of RAM do not post about how your emulator crashes,
    RAM is dirt cheap so invest some money into your PC.

    I would like to say thanks to squall_leonhart
    for posting this Solution.

sound replacements in roms

radorn

New member
Hello:

This is my first post as you may see but I've been reading these forums for some time now.
Well, hi everyone.
Now to the stuff:

You people seem to be a little confused about how sound works on the Nintendo 64 so I though I'd shed some light.

As you may already know the N64 hast a CPU and a co-processor called the Reality chip that takes care of sound and video (more or less like the GC's Flipper).
All previous mainstream consoles and handhelds used DEDICATED hardware for sound sythesizing: Genesis used a Yamaha chip fot that (like all prevous sega machines as far as I know), the SNES a Sony SPC700 custom unit, NES and GC use a dedicated chip too, PSX and Saturn also use dedicated hardware, but I don't know the specifics about that.

When you have dedicated hardware for some task you can roughly separate the code for that hardware and make it run independently just taking care you create an apropriate environment to make it think it is conected to what it spects to be to the needed extent. As so, in NES sound there is a SINGLE format for sound (not counting games with special EXTRA chips on the cartridge board for sound to add extra channels and sounds, like VRC6 from some konami games) and it can be more or less easily identified and ripped from the ROM images to a custom format (NSF in ths case). For SNES we have SPC, wich is excelently explained in this page http://www.alpha-ii.com/snesmusic/files/spc700.html.
Genesis ripped sound format is a logged one, which basically means that sound is played normally on an emulator and the activity and data of the sound chip is logged to a file for later playback, wich is a somewhat different way of doing things, but even with this, the data is stored somewhat in a recognisable way as it should be written for a specific DEDICATED hardware.

In N64 sound and video are sharing the same processor so there is not a dedicated DSP that does things in a standard way. rather than that, sound processing and synthesizing is coded for each game by it's developer separatly. In other words. each game makes music it's own way and there's no standard. Sound is synthesized by SOFTWARE and not hardware. There's no common functions, nor channels nor effects or a fixed sample rate. Each game is different.

you can read more info here (and get to know the USF format if you didn't already :D)
http://halleyscometsoftware/usf

long post for a first. isn't it? :p

hope you find this useful
 

loopsider

New member
zorbid said:
But then, better "sound fonts" could replace the hard-coded ones..

I wonder, where are these actual pre-stored sounds stored? In the audio plugin? In the emulator?

Good sounding soundfonts usually cost money, and the free ones that are out there are upwards of 50 megabytes in size.
 

.tekrox

New member
Replacing the Audio is N64 Games shouldn't be too hard; I remember A long time back there was a program that ripped the music and samples from the roms;

Comparativly N64 Music is more like Tracker Modules (ImpulseTracker, ScreamTracker, etc) than Midi; as they can use custom Samples and Riffs rather than just Hardware Sounds.

Replacing the Sound could be just as a simple as rewriting an old audio plugin to allow the use of custom samples; or to replace a hardware sound with a sample. IE. Replace the Ocarina in Zelda OOT with a nice Ocarina sample taken from a SoundFont or Recorded live, etc.
 

Turtleneck

Freelance Cartoonist
Is this is the program you speak of (Attachment)? Basically, you just drag n' drop a ROM onto the program, and it scans the sound banks/audio tables of the ROM and rips the WAVs to your C: drive; C:\Documents and Settings\%User Name% if you're using Windows XP.

Using no settings, I had it extract the audio from NBA In the Zone 2000, and only the music was ripped. (This game doesn't use instrument samples; it uses live, loopable music.) The WAVs were in 44100 kHz (Stereo) to my surprise.

I know that it works with:
Super Mario 64 (Voices, sounds, instrument samples)
Mario Kart 64 (Voices, sounds, instrument samples)
Mike Piazza's Strikezone (Voices, sounds, instrument samples)
Pokemon Snap (Voices, sounds, instrument samples)
International Track and Field 2000 (Instrument samples only)
NBA In the Zone 1999 (Instrument samples only)
NBA In the Zone 2000 (Music only)
 

radorn

New member
aibrubusfosusej said:
so, are you saying it's possible, not possible, or what?

I would say it is mostly unlikely. Some could games be done, but the method for one is unlikely to work for any other (well, maybe a couple of games COULD share the same scheme for music generation, but not much more). To make it possible you'd need to completelly bypass the sound system for each game, identify internal commands for music start, sound effects, and using a wrapper-like code to trigger your own code OUTSIDE of the N64 engine. And all that may be inssuficient or inaccurate, and it will SURELLY be different for each game out there.

Graphics plugins on N64 can have special functions because in the RSP (AFAIK) there's not code (or not VITAL code) to render graphics in the same fashion there is for sound. Graphics are processed by the CPU and just fed to the GPU (reality chip) for rendering. It means the GPU is fed STANDARIZED data about models textures and effects regardless of the game. and all it has to do is render them to 2D frames for display in your TV (or PC monitor in this case). In an emulated environment you cant take those models, translate them to a format good for your hardware or graphics library (Direct-X, OpenGL, etc) and in the process, change as many things as you want or can, because you have standard data to work on. wich means the data need to draw a given polygon with a given texture and whatever effects you want on it are ALLWAYS THE SAME, and not specific for each game, because there's no custom code run on the GPU for common tasks (maybe framebuffer effects like the big monitors in mario kart DO need some code in there, and those need special emulation code, I'm not sure about that)

All this is just my vision and limited knowledge about the specifics of the N64 hardware, but I regard the basics as fact and those basics are pretty determining.

I think it is NOT possible to do for sound the same Rice's plugin do for textures.

-------- EDIT ---------

There are tools that could rip sounds from N64 roms, but mostly for older games that used CERTAIN forms to store those sounds.

The point is NOT ALL GAMES use the same way. More like little games use the same way or even THAT way. Most games use custom formats, storing schemes, playing routines, etc.

not that the same doesn't apply to the graphics, but in graphics the process of that custom data is done on the CPU and just fed to the RSP (GPU, reality chip or whatever you call it) in a standard way for rendering.

Sound needs special code because the RSP is not a DAC (well, not ONLY a DAC)

------ EDIT 2 ------

(I'm getting addicted to this function)

to say things clearer (I hope) with graphics as with sound already rendered all you can do is filter or intelligent editing (like developing an IA that could do that, wich would be impossible today for humans as we know us now) as you would do with photoshop or a sound editor (note that filtering is actually something like automated edition opposing manual edition).

In N64, as it has accelerated 3D, we can intercep the data from the CPU/memory and process-render it in a new and hopefully better way that the original hardware could do not, like adding more and better filtering, higher screen resolution, and now texture substitution.

But sound is all handled by software (running on the RSP, wich is not CPU but a co-processor, but software after all), and each software can be different, and it actually is most times.

If we were to change that we would need to rewrite that software, wich being embedded on a rom would prove EXTREMELY difficult and crafty, and that for each rom. And we would face a new problem. as graphics rendering and sound processing are handled on the same chip (and developers balance the load for the two) we could find ourselves with not enough room to make better more complex sound because of a resource lack. So we would need a better hardware for our N64 but compatible with the old one... Any one up for the challenge???

You gurus of the emulation, correct me if I'm wrong, please.
Until that. I would say, again, it is not feasible to change music in N64 the same way textures are.
 
Last edited:

Top