Previous Page | Next Page
- by bxaimc at 8:05 AM EST on February 12, 2015
- Does it sound any different? ._.
- by nothingtosay at 1:01 PM EST on February 12, 2015
- Well, Lunar's recording sounds like normal speed to me (and clearly faster than the USF), but we shall see if there is a difference at all between the hardware regions.
- by bxaimc at 3:53 PM EST on February 12, 2015
- The usf rip was always broken though. It plays slower than any recorded material.
- by kode54 at 5:46 PM EST on February 13, 2015
- https://www.dropbox.com/s/mfr6o1rzyzy6fdg/Zelda_Ocarina_of_Time_tests.flac?dl=0
- by nothingtosay at 10:24 AM EST on February 14, 2015
- @bxaimc: Well, I made the thread after talking in IRC with people and hcs had wondered if that had been proven. I know I'd heard it for a long time, but figured it was worth asking for recordings.
Thanks for the FLAC, kode54. I can say there are no substantial differences in timing between NTSC and PAL versions based on the two recordings I've got. As for the difference between the USFs and hardware, the USF is 0.46% slow compared to kode54's recording and 0.48% slow compared to Lunar's. To be as exact as I can, I made clips of about two loops of "Kokiri Forest" covering the same musical area, aligned down to the sample as near as I could do. The one from Lunar's is 3,942,917 samples in length (89.408549 seconds); kode54's is 3,943,650 samples in length (89.425170 seconds); the USF when resampled to 44.1 kHz is 4,127,942 samples in length (93.604127 seconds).
But in the course of examining these files, I took interest in another thing that has come up a few times in the relatively recent past here.
kode54, would you agree the N64's output appears to use cubic interpolation? Maybe that's documented or something somewhere, I don't know, but that's what it looks like to me, with a lowpass filter starting at 16 kHz and attenuating by about 20 dB at 22 kHz. I'd be interested to have a look at a higher sampling rate recording to see how the filter is designed to work above that point and a recording of a game like Goldeneye, Banjo Kazooie, Perfect Dark, Pilotwings 64, or Mario Kart 64 to see the output from these games that all use sub-30 kHz internal sampling rates. Playback of the USFs might require resampling with cubic interpolation to sound more accurate to the hardware's output. It's not going to do much on soundtracks that use a ~32 kHz sampling rate, but it has a very apparent effect on those around 22 kHz.
edited 7:09 PM EST February 14, 2015
- by kode54 at 9:16 PM EST on February 14, 2015
- The N64's output uses nothing. Examination of the HLE RSP, which duplicates the behavior of the widely used RSP libraries, uses a lookup table based 4 point cubic interpolation resampler.
https://www.dropbox.com/s/eq3lhllgjk9midr/Legend_of_Zelda_Kokiri_Forest_recording.flac?dl=0
So, in your expert opinion, is the pitch also wrong, or is it only the tempo?
- by nothingtosay at 11:28 PM EST on February 14, 2015
- It's quite flattering for my opinion to be called expert by someone of your stature. :)
The pitch is definitely right and timing is the only problem. Which is kind of unfortunate in a way, since if the pitch were flat simply adjusting the playback rate, as is possible with foobar, would fix both pitch and timing issues without any drawbacks. Instead we either have to live with one problem or the other or use a DSP that speeds the sound up without altering its pitch, which can cause negative artifacts, though I'm pretty happy with it and find it worth doing.
And further thanks for the speedy 192 kHz recording. This one actually makes me think the lowpass filtering I mentioned was done either by your recording device because it was set to 44.1 kHz or through downsampling if you had recorded it at a higher rate originally. In any case, the new one leads me to believe there is no lowpass filtering.
I'm not knowledgeable enough about how the N64 and emulation of it works to confidently interpret your statement. So are you saying that 64th Note/LazyUSF's emulation already does cubic interpolation (but still outputs at the original sampling rate)? And does the RSP itself do cubic interpolation on actual hardware?
- by kode54 at 5:13 PM EST on February 15, 2015
- All of the sound processing in the N64 is done in software, similar to the GBA, only with significantly more powerful hardware available to perform the synthesis.
Of course, most games didn't want to waste so much of the RCP power on audio list (ALIST) processing, so they usually mixed at lower sample rates.
The HLE RSP emulator currently employed by Mupen64Plus, which I have even passed some contributions on to from JoshW, is a good documentation example on how the typical RSP ALIST processor works.
In the case of the nead processor used by Ocarina of Time and Japanese Majora's Mask original release, revision A, and PAL beta, and another revision used by all other releases of Majora's Mask.
Check out my lazyusf repository on Bitbucket, in the rsp_hle subdirectory, specifically in the alist_nead.c file, at the alist_process_nead_oot and _mm functions. Audio lists consist of an opcode number and parameters for that opcode's function. Mixing batches typically involve an interleaved set of commands for DMA transferring blocks of compressed sample data to the RSP's RAM, decompressing them, resampling them to the target frequency (using a common cubic interpolation function and coefficient table), applying any ADSR envelopes or volume scaling, then adding the result into a mix output buffer, which is then DMA transferred back to the main RAM, and eventually played by the DAC hardware.
Nead has functions for both cubic interpolation and zero-order hold, aka no interpolation.
Now, if we really want to fix timing, we need to figure out what timing mechanism the R4300i code is using for its synthesizer loop. The N64 features multiple timers, which trigger interrupt requests. The music code can be multi-threaded, as in there may be one process that runs in the DAC DMA interrupt that runs the RSP ALISTs to fill the output buffers. Then there's processes that run in the timer interrupts that actually update which sounds are playing, starting and stopping notes according to the music data.
There could be a timing error with the timer interrupt used by the music code. It can't be an instruction timing issue, at least for the R4300i, since being a MIPS processor, it has fixed timing per instruction.
This calls for further investigation.
- by Lunar at 2:18 AM EST on February 16, 2015
- Ocarina of Time isn't the only game with speed problems, btw. Actually most of the USF sets seem to play too slowly, if I remember correctly.
- by nothingtosay at 10:38 AM EST on February 16, 2015
- That's what I was going to say as well because kode54 gave me a recording of Donkey Kong 64 and it is also faster than the USF, though to a different degree than Ocarina of Time. The track I compared is "DK Rap" (naturally) and the recording is 192 kHz, so resampling the USF and cutting it down to the same selection of music results in this:
N64: 34,850,122 samples (181.511052 seconds)
USF: 35,545,295 samples (185.131745 seconds)
The USF is therefore slightly under 2% slow compared to more than 4.5% for Ocarina of Time. [At risk of drawing more attention to it than otherwise would have happened, I'm embarrassed to see in my previous statement of Ocarina of Time's speed deviation that I didn't move the decimal and consequently gave a drastically wrong percentage figure - yikes.]
This recording also indicates to me again cubic interpolation is used in the resampling. I should point out that kode54 was talking about interpolation being done in the mixing stage where the instruments in the sound banks are resampled to the target global sampling rate of the game, i.e. Ocarina of Time's 32006 Hz and DK64's 21617 Hz. However, the recordings of both of those games contain frequencies above the Nyquist limit that must be created after the mixing, likely at the DAC output's oversampling and reconstruction filtering, and that appears to also be using cubic interpolation.
In sum, a second recording of a different game supports Lunar's assertion that most USFs are slow and my hunch that resampling using cubic interpolation must be done to emulate the digital-to-analog stage of Nintendo 64 sound playback (this can be achieved using kode54's own MultiResampler foobar2000 component).
And if you've got a Nintendo 64 from any region and the capability of making recordings, preferably at 88.2 kHz or above though I wouldn't turn down lower, of any game for which there is a USF set, I'd be happy to get further samples for comparison.
edited 3:46 PM EST February 16, 2015
Previous Page | Next Page
Go to Page 0 1 2
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source