NPSF and Garbled Sound by Sqrfrk at 4:44 AM EDT on May 3, 2010
I've recently extracted some NPSF files from a different Namco PS2 game released around 2002, and tried doing a blind run of the files using the in_cube plugin. The result is a LOT of noise, but the melody can be heard in the background if you listen closely enough.
I'm trying to debug the issue, but I'm painfully ignorant about what might be the cause of noise. I've checked through vag.c on the .38 release and attempted to step through the header of the file, giving the following values:
Does this sound reasonable? Oddly enough, the initial .23 version of the plugin sounds clearer than the latest version with the fixes. Would anyone have any idea what might cause the garbled sound on top of the melody?
If anyone's interested, here's a sample file: a041.npsf
Why are you using in_cube, instead of VGMstream? I'm fairly certain that NPSFs are supported with VGMstream, which is significantly newer and more supported than in_cube. Try that first, and see if you're still having problems. Though, be sure to read the readme.txt first, as you'll be needing some additional DLLs for VGMstream to work. If you're still having problems, after trying VGMstream (and making sure that it's working), then maybe someone can figure out what the real problem is. Hope that helps. Mouser X over and out.
Thanks for the reply! I didn't realize that there was a newer dll form until I read it.
In any case, I'm still getting crackle and noise (the melody can still be heard, though). I went ahead and checked the ps2_npsf.c file and found that the essentials are filled out the same way using the same spots in the header as the in_cube source that I've looked at.
I also noticed that at start_offset = 0x800, there's about a block of 752 null bytes. Is this what should be expected?
This is really odd, it seems like every so often one frame is just a bit too long, which throws the whole stream out of sync... have any of the PS ADPCM specialists seen something like this before?
I'm wondering if the NPSF files I have were constructed from a different, outdated spec.
I'm clueless as to what makes a valid audio file - I had the assumption that this particular format has the header as listed in the source with RAW PCM appended after. After reading the 44100 sample rate, I just went through an "Aha, this must be the same!" line of thought.
There are blocks of null bytes interspersed throughout the file, though I'm not sure if this really matters.
Here's an attempt to deal with these by throwing out the excess bytes: unscrew 0.0 It doesn't work perfectly but it shows that at least in general this is mostly valid PS ADPCM. We may need to actually have the decoder use those excess bytes. I haven't been able to find any rhyme or reason to when the extra bytes show up yet, though. Could you upload another file? It'd be interesting to see if the pattern is the same.
Think I finally figured it out. Did you by chance ever transfer this file via FTP in text mode, or anything similar? It looks like something did a LF to CRLF conversion on this file.
EDIT: Actually, I did pull the archive from the DVD onto disk (WinXP & Win7) before I actually worked on it with my code...would that cause the CRLF conversion? The extractor code I wrote was also fairly half-assed C++ STD read/write, though I don't know if that made any programmatic difference.
Unscrew indeed. Thanks for the insight!
I'm assuming that a single frame is made up of 16 bytes delimited by a null byte, and for some reason the file has 1~3 of these as a delimiter giving a nice twisty picture. Feel free to tell me if I'm way off base.
There were a few that didn't follow the pattern though, using (0A, 0B, 1A, 1B, 19?) in lieu of the extra 00. Here's another sample: a060.npsf
I'd normally be willing to upload the entire archive but it's fairly large (> 1.8GB) due to voice and script files. And copyright concerns...if that matters any.
I think the problem is just that something is treating these files as text, which is corrupting them. You will want to check your extractor, and any file transfer tools if you used them. unscrew 0.1 does a better job (but not perfect) and it makes the assumption that 0a has been turned to 0d 0a, which Windows will do with text files.
unscrew will never be able to handle these perfectly, you really have to just avoid screwing the files in the first place.
I'll try whipping something up in C and try re-extracting directly from the DVD. It certainly would explain a few things with the other assets that were extracted.