From Newsgroup: comp.arch
On 1/22/2026 7:04 PM, Chris M. Thomasson wrote:
On 1/22/2026 4:13 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 1/22/2026 5:31 AM, Tim Rentsch wrote:
Michael S <already5chosen@yahoo.com> writes:
On Sat, 6 Sep 2025 05:28:16 -0500
BGB <cr88192@gmail.com> wrote:
Just randomly thinking again about some things I noticed with audio >>>>>> at low sample rates.
For baseline, can note, basic sample rates:
-a-a-a-a 44100:-a Standard, sounds good, but bulky
-a-a-a-a 32000:-a Sounds good
-a-a-a-a 22050:-a Moderate
-a-a-a-a 16000:-a OK, Modest size, acceptable quality.
-a-a-a-a-a-a Seems like best tradeoff if not going for high quality. >>>>>> -a-a-a-a 11025:-a Poor, muffled.
-a-a-a-a-a 8000:-a Very poor, speech almost unintelligible (normally). >>>>>> -a-a-a-a-a-a-a But, it is seeming like a "weird hack" may exist here. >>>>>
8000 x 8bit (mu-law in USA, A-law in majority of the world) was a
standard sampling rate for digital back ends of analog wired telephony >>>>> for more than 50 years.-a I didn't check, but would assume that it
still
is.
Most people founded it quite intelligible.
Yes but bit rate isn't the whole story.-a First the measure is not
"good sound" but only "understandable sound".-a Second telephony
does frequency filtering in a very different way than digital
audio does.-a Voices on phones are recognizable but still easily
differentiable from the original.-a Music played via phone-quality
audio sounds terrible.
In general, A-Law generates better sounding audio.
But, at low sample rates (eg, 8 kHz), I had noted that ADPCM gives more
intelligible speech than A-Law, even if the A-Law "sounds nicer".
I am not listening for the sound to be good or bad, I am listening
whether {the violin sounds like a violin, the trumpet sounds like a
trumpet, and the drums sound like drums} when listening to them live!
That is what was the hallmark of "Hi Fi" when I started (1965-ish.)
-----------------------
In my past testing, seems like 2kHz to 4kHz is the most important band
for speech intelligibility (at least for me). It is improved with the
4kHz to 8kHz band, but it seems like this is less important.
The timber of instruments requires phase accurate reproduction of
frequencies up to at least 15KHz.
Well now...
https://youtu.be/Ze4soU1nK1w?list=RDn13GHyYEfLA
Been a while since people have referenced Undertale much...
Though, ironically, had noted that the Undertale/Deltarune art style
does seem to align with how my dream world looks, which seems curious
(as from descriptions, apparently most people dream in a more
natural-looking full color thing, not so much high-contrast
mostly-monochrome, or with some 16-color like stuff going on).
Like, can't really explain it, it is like my brain is too cheap to
afford color depth (or even analog grayscale). Yet, my normal vision has
full colors and gradients (it is like, when "importing" images, my mind simplifies them, maps out the edges, and then blows out the contrast).
Or a wonderful game song, live:
(love this one! wow.
Aquatic Ambiance - Big Band Jazz Piano ft. Smart Game Piano (The 8-Bit
Big Band)
https://youtu.be/5znrVdAtEDI?list=RD5znrVdAtEDI
I kinda liked some of the 90s Sonic games music.
It was MIDI/FM based, but mostly well done.
Actually, 90s was notable, as many games did "actually good" music.
MIDI and Tracker music often having a special quality here, more so if
the song is good.
Vs, say the 2000s, where seemingly much of the industry was like "hey,
why don't we use a bunch of crappy garage band music!" and, mostly just
kept doing so.
Then, people mostly remember the game songs where someone does something
nice sounding with MIDI or trackers or similar. Not so much the ones
where someone is yelling in the microphone and doing blaring guitar sounds.
...
Well, not much notable recently...
A while ago, added SCAD model support to BGBCC;
Then implemented SIMD stuff for RV and XG3;
Then tweaked the ABI rules;
Then went and implemented some backprop neural net stuff;
Then partially reversed a few changes to default ABI for XG3:
Going back to using the 8-argument-register ABI as default (*1);
Then, debugging the SCAD stuff I had added to BGBCC.
*1: Where, say, 16 arguments in registers:
Slightly net-negative for performance in RV64G;
Helped for XG3 performance, but mismatched ABI leads to issues;
Temporarily went with 8 args for RV64 but 16 args for XG3;
But, then ran into some mismatch annoyances;
Ultimately, made more sense to stick with the 8-argument ABI as the
default for both RV and XG3 targets.
Did stay with having moved F4..F7 over to being callee-save, as this did
help in both cases.
After I started trying to make more use of BGBCC as a tool for
converting SCAD models, I have started ending up needing to debug it; as
as-is it is still pretty incomplete and buggy (doesn't take much to
stumble on bugs here).
Mostly, in this case, was fiddling some with stuff in my BT3 engine,
where BGBCC's core has ended up being used as the asset converter and packaging tool.
Like, well:
Compiles C code;
Converts files for the resource section;
Can pack WAD2 and WAD4 files;
Can convert images;
Can convert sound effects;
Can turn SCAD scripts into BMD models and similar.
Then again, the PEL resource section is essentially WAD based, and a lot
of the file-conversion stuff can be used in either case (except maybe
that SCAD is a bit much... but ironically, could leverage some other
parts of the C compiler).
Had I wanted to do a SCAD interpreter otherwise, would likely have
needed to leverage the core of a JS interpreter or similar, but maybe
might have made more sense than making use of a hacky interpreter that
was built on top of the "expression reducer" (which in turn exists as
part of BGBCC's front-end optimizer steps).
It is in some ways, a very stupid way to do an interpreter (as it
effectively evaluates things via expression rewriting), but, yeah... Generally, SCAD scripts are not exactly bound by the evaluation parts,
more by the CSG parts. But, it is somewhat higher level than, say, the
Quake "Brush Model" system, which exists as an intermediate step.
So, say:
Parse SCAD script, as a vaguely JS like syntax;
Evaluate script, in this case results in a tree of primitives replacing
the original AST;
Convert this tree into brush models and unions and similar;
Build and clip the polygons;
Convert to a 3D model in the desired format;
Add to target packaging.
So, in some sense, it works, even if, essentially, using a C compiler to convert SCAD scripts into 3D models and package assets seems kinda stupid.
But, the BT3 engine and TestKern are ending up using some similar tech:
WAD2 and WAD4: Yep;
BMP: Yes, for some things.
BT3 uses 16 color and 256 color BMP images for some uses.
WAV (ADPCM): Yep.
Don't have much "obviously better" than ADPCM for my uses (*1).
XML: Yeah, both BGBCC and BT3 have ended up using XML.
UPIC: Yeah.
Ended up going with UPIC with a transode to DXTn path.
Originally, BT3 was using DDS, but DDS has drawbacks.
UPIC has some advantages over both JPEG and PNG here (*2).
*1: For the weaknesses of ADPCM, there is pretty much nothing that
competes well against it in my uses. Basically: Something that is cheap
and simple to decode and can do "doesn't sound like crap" audio in the
16-32 kbps range (8000/11025/16000 2-bit mono, and 8000 4-bit mono).
4000-6000 2-bit mono is possible, but pushing the sample rate below 8000 usually does not result in passable audio quality. For the BT2 engine,
had used some 5512 Hz ADPCM for BGM (with some filtering trickery), but
for the BT3 engine am mostly using S3M for music.
Though, S3M can itself risk bulk it the patches are too large. If I were designing the format, would likely go with MIDI format but with patches
stored in ADPCM. But, tracker software doesn't really support this and
this decays back to wavetable based General MIDI, and the lack of a
good/free option for a GM wavetable. Did previously hack something
together using scavenged audio, but my improvised wavetable failed to
sound better than using FM synthesis (and scavenging the MIDI FM
parameters from the "GENMIDI.DAT" lump from FreeDoom).
But, alas, harder to make a good sounding General MIDI wavetable when
some amount of the patches were themselves derived from edited FreeDoom sound-effects and similar (it being otherwise difficult to do provenance
for the copyright status of sound-effects). But, at a certain level of
crappy, pretty much anything can be made to sound like a musical
instrument (even with the crappiness of "listen to instrument sound,
look for a sound effect that contains something 'kinda similar' that can
be edited out"; then just sorta shoved into a WAD as a bunch of blobs of
8kHz APCM).
But, otherwise, for the BT3 engine ended up going with S3M and my
lackluster musical skills. As, while many (and much better) MOD and S3M
music exists, options that work well as BGM and also are royalty free,
is harder. Well, and some amount of what I had made, is either
repetitive patterns, or using a similar strategy to that previously
described by Cryiak and Vihart, namely doing the melody by picking a
popular numeric sequence and laying out the digits as notes (for however
many notes one needs for that part of the pattern); often results in
something "slightly creepy".
But, would make no pretense of being a musician here.
*2: UPIC:
Structurally similar to T.81 JPEG, but:
Uses a TLV packaging scheme;
Uses STF+AdRice rather than Huffman,
with an LSB first bitstream
Z3V5 with a Deflate-like VLC coding.
Uses Block-Haar and RCT rather than DCT and YCbCr.
Both computationally cheaper and reversible.
Also has blocky CDF-5/3 and YCoCg and similar as options.
Natively supports an alpha channel.
Lossy compression seems competitive with T.81 JPEG;
For many images, compresses better than PNG and is faster to decode;
Supports lossless image storage.
UPIC is a nonstandard format, but this is less of an issue when used for textures.
It ended up winning out vs BMP+BT5B: BT5B is inherently lossy, and while
it can support smaller images than DDS, for functional reasons it fails
to achieve better Q/bpp than using DDS (and, "like DDS, but more
complicated to load" isn't super compelling). BMP+CRAM8 could also serve
a similar role (can be smaller than DDS, but looks worse).
While not the fastest option, UPIC ended up "less bad" in other areas,
and texture loading mostly isn't CPU bound. Bolting a DXTn decoder
directly onto the block decoder is a trick I had used with JPEG decoding.
...
--- Synchronet 3.21a-Linux NewsLink 1.2