Forums

The SMS version runs at 50hz. GG runs at 60hz. Sample rates are for conversions. Half that for the original 4 bit?

smp.rate Loc Length
6390 36A9A FF0 (SMS)
6448 36A9A FF0 (GG)

For completeness I am including the GG version as well (exactly the same) Just change the sample rate.

Also included precise logged vgms. The first is logged before the vdp is started (line 0). The next is run in-game and same result was achieved throughout. Each took 1110 cycles with only minor differences in the average across the whole.

(Bram Stoker's) Dracula (SMS) - 01 - Dracula.mp3 (31.83 KB)
logarithimic

(Bram Stoker's) Dracula (GG) - 01 - Dracula.mp3 (31.22 KB)

(Bram Stoker's) Dracula (SMS)(PCM).zip (2.21 KB)

(Bram Stoker's) Dracula (GG)(PCM).zip (2.2 KB)

exactly same data

(Bram Stoker's) Dracula (SMS-GG)(PCM-VGM).zip (24.6 KB)

precise logs

The sample seems to be linear (silence at level 8) so that's the clearest conversion. Can you list cycles per sample as well as the effective sampling rate at the chosen master clock? I don't understand what you mean by "Half that for the original"?

I think I've been misunderstanding things, like 8 bit conversions increasing the sample rate. I've been confused why 8 bit and 16 bit conversions work with the same sample rate. I've been assuming 4 bit is half..

Here are the figures
Game Name Sample Clock cycles full length avg cycle TV Type sample 8 bit sample rate PH Loc length
Dracula (SMS) Dracula 4529209 4080 1110.100245 PAL 3195 18F6 6390 36A9A FF0
Dracula (GG ) Dracula 4529219 4080 1110.102696 NTSC 3224 1930 6448 36A9A FF0

So both samples have ~1110 cycles. I thought it would be significantly faster for GG, but the wave playback isn't affected by frame interrupts (outside a small delay) so the main figure is the clock rate which isn't very different between the two. It results in the GG sample being ~.01 seconds shorter. It's probably a bit less/more than this, since I have't bothered to calculate it to higher precision.

I thought they would be different, but the samples are identical datawise, and only vary slightly in sample rate.

It could be that since they are 4 bit, we duplicate the rate due to there being two nibbles per sample? At this point, I lose confidence in what the math means..I just know it sounds correct at that rate...

Could you clarify the math?

I'm using 4 bit Sample rate= Clock/(cycles/lenght) or Clock/avg_cycles, though in practice it hasn't made a difference. Minor decimal differences. I've checked both.

I then multiply by 2 assuming some change in what the 8 or 16 bit conversions are doing. Not sure how the nibble factor gets calculated. Halving the rate makes no sense Cycles/Length*2, so I double the rate. That value worked when I added a 4 bit header to the file, but I had to double it when working with your tools.

At 4 bits, there's two samples per byte. The sampling rate is the number of points per second, nothing to do with the bit depth. So maybe that's where the confusion comes from.

For accuracy, it's best to convert the bit depth and keep the original sampling rate. You can resample to 44kHz but there's not much point.

You do realise that mp3s only support "popular" sample rates, right? At the lower end there are 8000 and 11025, but chances are that you're resampling anyway if your pcm uses a weird sample rate. Under this point of view, ogg would be a better alternative for a compressed release. But still, uncompressed waves should be used for preservation.

I had a vague idea of that but I hadn't bothered to check. We'll preserve the raw stream and document the format, the MP3s are for listening on the web.

Yeah. I ran into that issue when trying to use lame. I kept getting ugly results so went back to manually exporting from audacity.

Since they are so small, I wondered why mp3 files were preferred over wave, but the answer seems to be "for presentation".

Audacity forces a 32000 or 44100 standard, so I'll use the lower one moving forward. Do you know how to set the proper conversion rate using lame? Or do I just use -s 44100. Sox was a bit confusing to work with, but I didn't get the results I wanted with lame. Happy to hear it's supposed to be that way.

I'll try to make a sensible guide for how to present this stuff soon... MP3 is the only viable option on the web, but we should pick an encoding standard. Sometimes we can package the original data as WAV so we should do that too. More work is needed to make sense of it all.

Yeah I agree. I am working much slower than I probably have to. Only part of that is due to unfamiliarity or tools. A lot of it is checking different things. I've only worked on obvious compressed examples so far.

Maybe it's time I picked something slightly more complicated. But still with not too many samples.

saving the test wav files at 8192 gives a better result. The PCM sounds closer to normal, and I just have to divide the current sample by 2 to get the address. Dracula and Krusty both have 88 88 78 78 88..etc commands common. Alex kidd is a bit different.

Author	Message
sherpa Joined: 28 Nov 2014 Posts: 365	[PCM Voice Pack] (Bram Stoker's) Dracula (SMS) / (GG) Posted: Sun Dec 20, 2015 12:25 pm Last edited by sherpa on Sun Dec 20, 2015 2:37 pm; edited 2 times in total
sherpa Joined: 28 Nov 2014 Posts: 365	The SMS version runs at 50hz. GG runs at 60hz. Sample rates are for conversions. Half that for the original 4 bit? smp.rate Loc Length 6390 36A9A FF0 (SMS) 6448 36A9A FF0 (GG) For completeness I am including the GG version as well (exactly the same) Just change the sample rate. Also included precise logged vgms. The first is logged before the vdp is started (line 0). The next is run in-game and same result was achieved throughout. Each took 1110 cycles with only minor differences in the average across the whole. (Bram Stoker's) Dracula (SMS) - 01 - Dracula.mp3 (31.83 KB) logarithimic (Bram Stoker's) Dracula (GG) - 01 - Dracula.mp3 (31.22 KB) (Bram Stoker's) Dracula (SMS)(PCM).zip (2.21 KB) (Bram Stoker's) Dracula (GG)(PCM).zip (2.2 KB) exactly same data (Bram Stoker's) Dracula (SMS-GG)(PCM-VGM).zip (24.6 KB) precise logs

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Dec 20, 2015 1:30 pm
	The sample seems to be linear (silence at level 8) so that's the clearest conversion. Can you list cycles per sample as well as the effective sampling rate at the chosen master clock? I don't understand what you mean by "Half that for the original"?

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Sun Dec 20, 2015 2:05 pm
sherpa Joined: 28 Nov 2014 Posts: 365	I think I've been misunderstanding things, like 8 bit conversions increasing the sample rate. I've been confused why 8 bit and 16 bit conversions work with the same sample rate. I've been assuming 4 bit is half.. Here are the figures Game Name Sample Clock cycles full length avg cycle TV Type sample 8 bit sample rate PH Loc length Dracula (SMS) Dracula 4529209 4080 1110.100245 PAL 3195 18F6 6390 36A9A FF0 Dracula (GG ) Dracula 4529219 4080 1110.102696 NTSC 3224 1930 6448 36A9A FF0 So both samples have ~1110 cycles. I thought it would be significantly faster for GG, but the wave playback isn't affected by frame interrupts (outside a small delay) so the main figure is the clock rate which isn't very different between the two. It results in the GG sample being ~.01 seconds shorter. It's probably a bit less/more than this, since I have't bothered to calculate it to higher precision. I thought they would be different, but the samples are identical datawise, and only vary slightly in sample rate. It could be that since they are 4 bit, we duplicate the rate due to there being two nibbles per sample? At this point, I lose confidence in what the math means..I just know it sounds correct at that rate... Could you clarify the math? I'm using 4 bit Sample rate= Clock/(cycles/lenght) or Clock/avg_cycles, though in practice it hasn't made a difference. Minor decimal differences. I've checked both. I then multiply by 2 assuming some change in what the 8 or 16 bit conversions are doing. Not sure how the nibble factor gets calculated. Halving the rate makes no sense Cycles/Length*2, so I double the rate. That value worked when I added a 4 bit header to the file, but I had to double it when working with your tools.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Dec 20, 2015 4:56 pm
	At 4 bits, there's two samples per byte. The sampling rate is the number of points per second, nothing to do with the bit depth. So maybe that's where the confusion comes from. For accuracy, it's best to convert the bit depth and keep the original sampling rate. You can resample to 44kHz but there's not much point.

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Sun Dec 20, 2015 6:31 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	You do realise that mp3s only support "popular" sample rates, right? At the lower end there are 8000 and 11025, but chances are that you're resampling anyway if your pcm uses a weird sample rate. Under this point of view, ogg would be a better alternative for a compressed release. But still, uncompressed waves should be used for preservation.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Dec 20, 2015 6:34 pm Last edited by Maxim on Sun Dec 20, 2015 7:10 pm; edited 1 time in total
	I had a vague idea of that but I hadn't bothered to check. We'll preserve the raw stream and document the format, the MP3s are for listening on the web.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Sun Dec 20, 2015 7:09 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Yeah. I ran into that issue when trying to use lame. I kept getting ugly results so went back to manually exporting from audacity. Since they are so small, I wondered why mp3 files were preferred over wave, but the answer seems to be "for presentation". Audacity forces a 32000 or 44100 standard, so I'll use the lower one moving forward. Do you know how to set the proper conversion rate using lame? Or do I just use -s 44100. Sox was a bit confusing to work with, but I didn't get the results I wanted with lame. Happy to hear it's supposed to be that way.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Dec 20, 2015 7:13 pm
	I'll try to make a sensible guide for how to present this stuff soon... MP3 is the only viable option on the web, but we should pick an encoding standard. Sometimes we can package the original data as WAV so we should do that too. More work is needed to make sense of it all.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Sun Dec 20, 2015 7:31 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Yeah I agree. I am working much slower than I probably have to. Only part of that is due to unfamiliarity or tools. A lot of it is checking different things. I've only worked on obvious compressed examples so far. Maybe it's time I picked something slightly more complicated. But still with not too many samples. saving the test wav files at 8192 gives a better result. The PCM sounds closer to normal, and I just have to divide the current sample by 2 to get the address. Dracula and Krusty both have 88 88 78 78 88..etc commands common. Alex kidd is a bit different.

Forums

View topic - [PCM Voice Pack] (Bram Stoker's) Dracula (SMS) / (GG)