That's one thing I've found annoying, too, even when just doing ROM hacking. And even if you can convert WAV to BRR, that assumes that you both have WAVs that would work (not too big, loopable) and that you have a way to convert them accurately.psycopathicteen wrote:Something that I find a bottleneck is the lack of BRR sample libraries.
...and for the format:generate_brr_sample_library:
ldx #$00
-;
ldy #$00
lda ({source}),y
beq +
phx
jsr polygon_synth
plx
lda {brr_buffer}
sta {directory},x
sta {directory}+2,x
lda {brr_buffer}+1
sta {directory}+1,x
sta {directory}+3,x
inx
inx
inx
inx
tya
ldy #$00
adw {brr_buffer}
stw {brr_buffer}
bra -
+;
rts
polygon_synth:
ldx #$00
ldy #$00
str {temp}=#$00
lda ({source}),y
sta {countdown}
iny
lda ({source}),y
sta {header_byte}
-;
iny
lda ({source}),y
sta {temp2}
lda {temp}
iny
-;
clc
adc ({source}),y
sta {wave_buffer},x
inx
dec {temp2}
bne -
sta {temp}
dec {countdown}
bne --
txa
xcn
and #$0f
sta {#_of_blocks}
iny
tya
ldy #$00
adw {source}
stw {source}
jsr convert_wav_to_brr
rts
convert_wav_to_brr:
ldx #$00
ldy #$00
-;
lda {header_byte}
cmp {#_of_blocks}=#$01
bne +
inc
+;
sta ({brr_buffer}),y
str {temp2}=#$08
-;
lda {wave_buffer},x
and #$f0
sta {temp}
inx
lda {wave_buffer},x
and #$f0
xcn
ora {temp}
inx
iny
sta ({brr_buffer}),y
dec {temp2}
bne -
iny
dec {#_of_blocks}
bne --
rts
Code: Select all
byte 0: number of line segments in wave shape (0 means no more BRR samples)
byte 1: BRR header byte
repeats for "byte 0" amount of times
byte 2n+2: length in samples of line segment
byte 2n+3: 8-bit slope
Then it repeats for the next BRR sample until "byte 0" is 0.
Waves that are not divisible by 16, get clipped to the nearest multiple of 16.
Code: Select all
square_wave:
db $04,$92 //4 line segments, with BRR header of $92
db $01,$7f //first line, 1 sample long, with slope of 127
db $1f,$00 //second line, 31 samples long, with no slope
db $01,$01 //third line, 1 sample long, slope is 1 but wraps around to -128
db $1f,$00 //forth line, 31 samples long, with no slope
saw_wave:
db $01,$92 //only 1 line segment needed, with BRR header of $92
db $40,$04 //64 samples long with a slope of 4, wraps around
Such a library could be rather easy to make by taking a General MIDI sample set and turning all of them into BRR... although the quality to use is always a space/quality tradeoff we cannot take in advance without knowing the application.psycopathicteen wrote:Something that I find a bottleneck is the lack of BRR sample libraries.
You're supposed to record them from your syntesizer. All WAVs are loopable, whether the loop actually sounds good however is a different debate.that assumes that you both have WAVs that would work (not too big, loopable)
And what'd be the point exactly ?! It'd be the same trouble to find WAV files, *and* it would take more memory. The only point I see is that the 65C816 (or the SPC700) could automatically adjust the sample's quality depending on the song which is playing, so that it uses memory most efficiently at all times. Yet such a system would still be incredibly complex for small benefits (i.e. better sound quality for music pieces using few different samples), it sounds better to do this work manually on a case-by-case basis.I would like to see someone making a WAV to BRR code using either the 65816 or SPC700
Very interesting idea ! Especially if you can move the "polygon" during playback to create effects. Chrono Trigger does something like that but it just changes a pulse wave's duty cycle permanently.Earlier today I had the idea of a "polygon synthesizer" where the waves could be stored as straight lines of various slopes and legnths, as a way to create custom sounds without having to manipulate long BRR samples in hex
If you're doing polygon synth, you can doing the easy way and just generate 4-bit PCM samples (BRR filter is always 0), or do it the more CPU intensive way of figuring out which filter/range settting is best for which BRR block.Bregalad wrote:And what'd be the point exactly ?! It'd be the same trouble to find WAV files, *and* it would take more memory. The only point I see is that the 65C816 (or the SPC700) could automatically adjust the sample's quality depending on the song which is playing, so that it uses memory most efficiently at all times. Yet such a system would still be incredibly complex for small benefits (i.e. better sound quality for music pieces using few different samples), it sounds better to do this work manually on a case-by-case basis.I would like to see someone making a WAV to BRR code using either the 65816 or SPC700