proper settings for spc -> mp3?

SPC Questions

I'm wondering what the idea settings are to convert SPC -> MP3.

Some people seem to "up" the sample rate. SPC is natively at 32khz, but people seem to output them to 44.1khz.


What is the point of this? If it does somehow sound "better"... how does it? How can you sound better than the original source material?

If you burn a 32khz mp3 to a CD, does it upconvert to 44.1khz? I'm assuming yes but I don't really know. Is that the reason people do it?

So ultimately I'm wondering:

1) does it sound better at 44.1khz? if so, why/how?
2) if you save a 32khz wav as a 44.1khz mp3, how much space is lost? Is any quality lost? ie, is it resampled?
3) what settings do you think should be used when converting spc's to mp3s and why?

Jam it back in, in the dark.

1. There is no reason why it should sound any better. You do not lose quality when upsampling - but you don't gain quality either. You just make the file size bigger.
2. You will gain space (depending on your encode settings, mp3s are anywhere between 10% to 25% of the original wave file). Since you upsampled, you will gain less space. You DO lose quality when you save to MP3. With MP3, it is always a trade-off between space and quality.
3. Why do you want to do this, when SPCs are much smaller than MP3s (being limited to 64kb), and are lossless to boot?

There's nowhere I can't reach.

Originally Posted by Zergrinch

You do not lose quality when upsampling

Oh yes, you do!

I won't go into details here but correct upsampling is not a trivial task. Especially when upsampling from 32kHz to 44.1kHz or from 44.1kHz to 48kHz - a lot of cheap resampling circuits really screw up here.

The emu10k1 series by Creative Labs is an example for really bad internal resampling. If you have to resample (SRC = sample rate conversion) then use a pure software tool and one that does the job right (like Secret Rabbit Code (aka libsamplerate)). If you don't have to resample, then don't do it!

Most amazing jew boots

I still don't understand how the authors of SPC codecs can claim it sounds better..

some of their claims: Some SPC players, including SNESAmp, can even produce higher-quality output than the SPC700 itself by outputting the sound at a higher sampling rate (up to 192 kHz), using more complex sound interpolation methods and using a special "High Quality" enhancement feature (as in SNESAmp):

LiquidAcid, do tools like these lose quality when outting to a higher sampling rate?

I am a dolphin, do you want me on your body?

Originally Posted by penny

LiquidAcid, do tools like these lose quality when outting to a higher sampling rate?

When the ratio between destination sampling rate and source sampling rate is a natural number, then you don't degrade the quality. However this isn't the case for most applications.

In any other case the upsampling process is lossy. You can read a bit on the "Secret Rabbit code" site about the quality of such SRC.

I was speaking idiomatically.

I use the high-quality 44.1 settings of SNESAmp because it has a smoother sound to it than the default 32.

What kind of toxic man-thing is happening now?

Originally Posted by Kaleb.G

I use the high-quality 44.1 settings of SNESAmp because it has a smoother sound to it than the default 32.

Then your soundcard hardware / driver has problems with upsampling. Most chips use a internal sampling rate of 48kHz and resample all material to this rate before feeding it into the DAC. Like I stated above the resampling circuits are either crap or the resampling code in the driver.

Use an audio player that does the resampling for you using a high quality resampling like the SRC one. foobar2000 e.g. has a plugin that uses this resampler.

On linux you can use the ALSA plugin system to enable the usage of libsamplerate. Whenever an application is feeding material into the soundsystem which needs resampling this is done with the lib.

EDIT: Please keep in mind that resampling is not an easy task and therefore needs CPU time. Depending on the settings for SRC and the CPU power of the system this could be around 20%.

FELIPE NO

Just to clarify: The higher quality/frequency/bitrate settings in SNESAmp have nothing to do with upsampling, they affect the mixing process itself. Think of it as playing an old 3D game on the latest 3D hardware and thus being able to choose higher display resolutions, more and better AA etc. The textures (instrument samples) and the game scenes (music score) don't change, but some may like the improved processing.

However if you want to convert SPC files and want to claim it to sound like the real SNES you should pick the "like SNES" DSP setting, this disables all the additional flexibility that emulation can offer.

What, you don't want my bikini-clad body?

Originally Posted by LiquidAcid

uneducated babble

What datschge said.

How ya doing, buddy?

Originally Posted by datschge

Just to clarify: The higher quality/frequency/bitrate settings in SNESAmp have nothing to do with upsampling, they affect the mixing process itself.

Can you point me to some docs about this? SNESAmp has to emulate the SPC700 chip, so it has to stick to the specs of the chip. And AFAIK the chip always outputs the audio at a sampling rate of 32khz.

I might be wrong, but IIRC the SPC700 isn't really a waveform playback device. It's a microprocessor which you have to feed with your program code and then it generates the audio stream. I find it somehow hard to believe that you can simply increase the number of produced samples, because this (if I'm not wrong) would involve changing the program code that the "user" uploaded into the PU.

Originally Posted by datschge

Think of it as playing an old 3D game on the latest 3D hardware and thus being able to choose higher display resolutions, more and better AA etc. The textures (instrument samples) and the game scenes (music score) don't change, but some may like the improved processing.

That would mean that the SPC format is comparable to a tracker format. But is this really true?

EDIT: I want to emphasize that the only interesting thing I can find on the author's webpage is an article about audio interpolation. And the hint that the player uses the SNESAPU lib (however I can't find the project page for that one).

Most amazing jew boots

Well, the author of SNESAmp is the same as the one for SNESAPU. The SNES' sound unit comprises of the SPC700 CPU and the DSP it controlls. The SPC700 by itself makes no sound but just executes the program in the SPC files. The DSP makes the sound and can be implemented in a more loose way, and that's how the mixing can be improved. SNESAmp has these features since I bugged the author to do so, such features can be implemented as long as mixing is done in some hardware (i.e. most gaming systems except N64, GBA and afaik PSP which do sound in software). There is no docs except this basic one: SNESamp > SNES sound module If you don't want to believe me you can look at the sources of SNESAmp/SNESAPU.

This thing is sticky, and I don't like it. I don't appreciate it.

Originally Posted by datschge

Well, the author of SNESAmp is the same as the one for SNESAPU. The SNES' sound unit comprises of the SPC700 CPU and the DSP it controlls. The SPC700 by itself makes no sound but just executes the program in the SPC files. The DSP makes the sound and can be implemented in a more loose way, and that's how the mixing can be improved.

Ah, ok! I see now. So it's like they increase the internal clocking of the DSP unit but retain the cycles for the SPC700 unit. Still wondering how this works in detail, but I think I can figure this out from the sources.

Originally Posted by datschge

There is no docs except this basic one: SNESamp > SNES sound module If you don't want to believe me you can look at the sources of SNESAmp/SNESAPU.

Yep, I know this one, but it's very superficial and he probably wrote it for normal users to understand the concepts.

These ones go more into detail:
Super NES Programming/Loading SPC700 programs - Wikibooks, collection of open-content textbooks
SPC-700 Programming Information
http://www.alpha-ii.com/snesmusic/fi...apu_manual.txt

Thanks datschge for clearing that up. However my points still hold. If you play back 32kHz material on your system and it sounds really bad, try playing it back with fb2k and the SRC plugin.

Comparing the sampling rates of 44.1kHz and 32Khz the first one gives you a maximum freq of 22050Hz and the other one a maxfreq of 16kHz. I don't think that this makes a huge difference, especially considering that the programs that are executed on the SPC700 unit are written with the DSP specs in mind.
And like datschge already stated above: The SPC700 works like a tracker (I looked this up because I wasn't really sure about it), so you can upload samples and then execute your program which plays them back. To make use of a higher DSP sampling rate you would have to increase the amount of uploaded samples, and this surely cannot be done without modifying the uploaded program code.

I am a dolphin, do you want me on your body?

No, no, no. You still didn't get it. Think of synthesizers/DSP units like MIDI alike units, the unit sending the music commands (SPC700 in the SNES case) doesn't have to know the mixing rate or process, it's completely irrelevant to sending any music commands. As long the emulated synthesizer/DSP hardware is able to interpret all incoming commands correctly the mixing is irrelevant and doesn't need to stick to the original spec, this is how SNESAPU can and does allow for higher quality settings, and this can be implemented in any emulation of hardware synthesizers. Abstraction allows for flexibility. The interfaces to synthesizers/sound DSPs are already abstracted by their very purpose, they are not every world CPUs needing one to stick to ticks and cycles to work.

Most amazing jew boots

Originally Posted by datschge

No, no, no. You still didn't get it. Think of synthesizers/DSP units like MIDI alike units, the unit sending the music commands (SPC700 in the SNES case) doesn't have to know the mixing rate or process, it's completely irrelevant to sending any music commands. As long the emulated synthesizer/DSP hardware is able to interpret all incoming commands correctly the mixing is irrelevant and doesn't need to stick to the original spec, this is how SNESAPU can and does allow for higher quality settings, and this can be implemented in any emulation of hardware synthesizers. Abstraction allows for flexibility. The interfaces to synthesizers/sound DSPs are already abstracted by their very purpose, they are not every world CPUs needing one to stick to ticks and cycles to work.

OK, I think now I get it.

I always thought that the SPC700 already included the DSP part and that it was clocked at 32kHz, outputting one sampling every tick.

So they just "accurately" emulate the SPC700 PU, because that's the part the SNES main PU interfaces with. The DSP emulation is the part where the implementation differs from the original hardware design and it's also the part where the audio quality difference is generated.
The SPC700 is basically a frontend for the DSP and the SNES main PU doesn't inteface with the DSP directly, so you can make changes in the DSP emulation without breaking any opcodes / API / ABI stuff.

Is this correct?

EDIT: And sry for the off-topic noise. I'm very interested in low-level emulation techniques, so this is great stuff to know

What kind of toxic man-thing is happening now?