nesdev.org

Doesn't that kind of defeat the purpose? We're almost finished with this anyway. We got it compressed down to 48mb, with 16mb left over for audio.

I guess an MSU-1 video codec that takes care not to pull more than 150 KiB/s would be a counterpart to Sega CD: "This is what it would have looked like on the SNES CD had Nintendo not reneged on the deal with Sony."

psycopathicteen wrote:We got it compressed down to 48mb, with 16mb left over for audio.

So you are going to try to fit it into 8 MB.

That still leaves enough space for a monaural version of the high-frequency sample augmentation idea. Alternately, if the vocals can be separated out as a mono track, sequencing part or all of the rest of the track (possibly including vocal sibilants) as was suggested earlier would probably fit it in without much trouble, and in stereo too, though it probably wouldn't sound as authentic.

If I were doing this, I'd probably have an alternate version prioritizing audio fidelity over memory map compatibility (I'm a digital music person). But it looks like we're already doing fairly well, with enough space to beat the MD version even with an unadorned mono BRR...

MottZilla wrote:You could create a version using the MSU-1 extension

Of course. Possibly with higher resolution, and definitely with uncompressed Red Book audio. But that's cheating, at least until we've got a Sega CD version to compete with (and maybe even then)...

One of the Genesis versions compresses the sample to about 3 samples per byte, which is comparable to the ratio of the "MACE" audio codec from classic Mac OS. (I don't know how MACE works, but I do know FFmpeg decodes it.) I have an idea for how to hack BRR to reduce the data rate to 2.5 bits per sample instead of 4.5, which the S-CPU expands to full BRR through lookup tables while feeding the S-SMP. It involves expanding 2-bit units to 4-bit nibbles using [-5, -1, 1, 5] or [-7, -2, 2, 7] depending on an additional bit in the shift amount byte. It's simple enough that the S-SMP could probably do the expansion itself with a lookup table or two. I haven't tried it for quality though.

But [MSU-1 is] cheating, at least until we've got a Sega CD version to compete with (and maybe even then)

Perhaps it might inspire the Sega guys to try to beat us by creating a Sega CD version of the color version.

Ehh... It's a bit ugly... (It doesn't translate very as well) I'm guessing this isn't anything official, because the animations on the models are a bit stiff and some models have a surprisingly low poly count. An apple or a tea cup with a model that detailed looks fine when it is far away, like in a video game, but it looks like I'm watching a red octagon spinning when it's full screen. Also, Super Road Blaster really mops the floor with anything the FMV "game" the Sega CD produced. But I really wouldn't say that hardware released in 1991 was really meant to compete with hardware 20 years latter. (Even if both add-ons are still restricted by their parent hardware, which in that case, the SNES wins in terms of color.)

tepples wrote:One of the Genesis versions compresses the sample to about 3 samples per byte

Yeah, I saw that one. Sounds pretty bad, but with 4 MB for video and audio combined it's a pretty impressive job nonetheless.

I have an idea for how to hack BRR to reduce the data rate to 2.5 bits per sample instead of 4.5, which the S-CPU expands to full BRR through lookup tables while feeding the S-SMP. It involves expanding 2-bit units to 4-bit nibbles using [-5, -1, 1, 5] or [-7, -2, 2, 7] depending on an additional bit in the shift amount byte. It's simple enough that the S-SMP could probably do the expansion itself with a lookup table or two. I haven't tried it for quality though.

If that ended up sounding decent, it might be possible to combine it with the high-frequency sample augment scheme and get pseudo-32 kHz stereo. 16 Mbits is enough space for two channels at almost 15 kHz with a whole bank set aside for samples and program data.

I've been wondering about taking advantage of correlation between stereo channels to further compress a pair of BRR waveforms, but it seems complicated and I don't have time to think about it right now.

(This is all assuming the final video runs at 30 fps with enough headroom for APU handling, of course... I'm increasingly certain there's slowdown at several spots in the early version, but I can't get hard data because none of the emulators that have frame advance can run it...)

93143 wrote:it might be possible to combine it with the high-frequency sample augment scheme and get pseudo-32 kHz stereo.

Has anyone looked at the "MP3+v" experimental codec as a proof of concept for high-frequency augmentation?

I've been wondering about taking advantage of correlation between stereo channels to further compress a pair of BRR waveforms, but it seems complicated and I don't have time to think about it right now.

It's called "mid-side stereo". Encode (L+R)/2 at full rate and (L-R)/2 at a lower rate (lower frequency, lower ADPCM precision, etc.). Play L+R at full volume on both channels, and play L-R at 100% on left and -100% on right.

There are several approaches that can be used for the 32 Mbit version:

• Make a diagnostic tool to tell how the emulator is loading the ROM
• Audio with 2-bit BRR precision
• Use only 256 slivers
• Use only 16 slivers
• Reduce to 1024 distinct tiles, modulo hflip, vflip, and inversion, and store only nametable entries

tepples wrote:Has anyone looked at the "MP3+v" experimental codec as a proof of concept for high-frequency augmentation?

Link? The Googles do nothing... Never mind; I found it. Well, a forum thread from 2001 and a dead site, anyway, but I think I get the general idea...

The scheme I'm thinking of is pretty simple, really:

1) highpass the original track at half the target samplerate,
2) browse through the resulting high-frequency track and make samples out of anything that sounds important,
3) program the SPC700 to trigger these samples at the appropriate times/volumes/etc. while playing back the downsampled track.

I figured I'd try doing the first two steps myself to see what the result looked like, but I won't have time until next week.

It's called "mid-side stereo". Encode L+R at full rate and L-R at a lower rate (lower frequency, lower ADPCM precision, etc.). Play L+R at 50% volume on both channels, and play L-R at 50% on left and -50% on right.

Now that you mention it, it does seem kinda obvious - it's not like I've never messed around with mid-side before...

If your BRR hack turned out to work moderately well, using it on the side channel could result in nearly full quality streaming audio in a 12 MB ROM, assuming the decoded stream can be shoveled at the DSP fast enough. Alternatively, a sample rate reduction would accomplish roughly the same thing, though some high-frequency positional information would be lost.

I was imagining something more sophisticated somehow... but I guess there's a reason we aren't just using an MP3...

Espozo wrote:Also, Super Road Blaster really mops the floor with anything the FMV "game" the Sega CD produced. But I really wouldn't say that hardware released in 1991 was really meant to compete with hardware 20 years latter. (Even if both add-ons are still restricted by their parent hardware, which in that case, the SNES wins in terms of color.)

The Sega CD port of Road Blaster was pretty crap in the FMV department, it's like they just passed the FMV through a downsampler to 16 colors and that's it (it isn't even using multiple palettes, not to mention the reduced framerate). Pretty sure it could have been much better, but I guess they couldn't afford it.

At least everything else was alright, the new soundtrack fits the game better and they replaced the crappy dumb staff roll with a much better ending =P

How did most Sega CD games even deal with color? did they use multiple palettes, and possibly overlay BG layers for about 31 colors per tile? I'm guessing the screen wouldn't be able to have been updated in time.

Sik wrote:At least everything else was alright

With "everything else" being two things.

it's like they just passed the FMV through a downsampler to 16 colors and that's it

Well, it has dithering because, you know, dithering is definitely a good substitute for not even using all the color palettes.

Is byuu around?

I need to know if this is the correct seek macro for exHirom?
@Tepples, the "sba0topd" file is 4097kB. One kilobyte too big.

Espozo wrote:How did most Sega CD games even deal with color? did they use multiple palettes, and possibly overlay BG layers for about 31 colors per tile? I'm guessing the screen wouldn't be able to have been updated in time.

Depends on the time when it was released actually, but usually three or four palettes would be used for FMV (the size and framerate of the FMV changed over time as the decoder evolved). Remember each tile could use its own palette.

There is one game that does overlay two planes (Battlecorps), but it's not done for FMV =P (it updates at 15FPS, although it's just half the screen really)

Espozo wrote:With "everything else" being two things.

It's not like there's much more to the game =P

Espozo wrote:Well, it has dithering because, you know, dithering is definitely a good substitute for not even using all the color palettes.

That's the issue, they didn't even bother with that. There's a bit of dithering, but most stuff doesn't have dithering at all when it definitely was needed badly. In fact I wonder if the existing dithering isn't just a side effect of noise in the source video, because its patterns don't make that much sense either.

I think that shows how badly the conversion was.

psycopathicteen wrote:correct seek macro

Lessee ... to convert a mode 25 physical ROM offset (accounting for the weird inversion of A23), it should be
0x000000-0x3FFFFF ↔ $C00000-$FFFFFF
0x400000-0x7DFFFF ↔ $400000-$7DFFFF (unchanged, usefully)
And explicitly choosing to ignore the range mapped to $3E8000-$3FFFFF

So,
#define logical2physical(addr) (addr | 0x400000 | (((~addr) & 0x400000) << 1))

psycopathicteen wrote:@Tepples, the "sba0topd" file is 4097kB. One kilobyte too big.

Oops, my bad. It appears my chunker was defective: the first frame of a chunk would get repeated at the end of the previous chunk. Does the last kilobyte of the first file resemble the first kilobyte of the second file? If so, you can just chop it off. (Turns out it does; you can chop it at $3FFDF2.) I'll post new files if there are any other changes to make in the data.

Got the full video working. Now I have to get it running at a constant 30fps.