I don't think that my decoder is so much faster than others, and it's not the first to come up with the mono/half options. It's almost unthinkable to see a dos decoder without such features (even winamp has that stuff, hidden away under options, preferences, input, plugins, nullsoft mpeg, configure, decoder, stereo/half).

Most decoders that can play a 44Khz 256kbit stereo mp3 file on a 486 at 100MHz with full quality should be also able to play the very same file at 33-40 MHz with reasonably good quality.

For a 386DX-40, a coprocessor would probably only slow down the decoding, and the bitrate doesn't matter so much for the decoding speed, but it's probably required to use a mp3 with lower sample rate. If I may guess, I think that it could play a 22kHz 112kbit stereo file at full 22kHz in mono, which would sound pretty good.

And on a 386DX-33, maybe 16kHz would work, which would be still better than 11kHz. The bigger issue is that an authentic 386 comes with, say, a 134Mbyte harddisk (and, as far as I remember, those harddisks were much more expensive than a bunch of 90 min audio tapes).

I did test on my Cyrix 5x86 two times with a different set of CPU optional features. All other settings remained the same

Cyrix 5x86 120Mhz (4x40), 64MB RAM, 256K WT Cache, Msdos 6.22 (XMS ONLY)

Test 1 : Optimal safe features enabled
40,304 milliseconds

Test 2 : Max performance features enabled, mainly the branch predictor is enabled and the incompatible features with that later, disabled
37,661 milliseconds

nocash wrote on 2024-09-26, 03:24:

Most decoders that can play a 44Khz 256kbit stereo mp3 file on a 486 at 100MHz with full quality should be also able to play the very same file at 33-40 MHz with reasonably good quality.

Which are those most decoders? And I mean an "OK quality" MP3 file (128kbit stereo) to be played on 486SX*/DX-40 CPUs.

* - Well, maybe coprocessor is not needed for faster floating point or signal processing calculations

I`ve uploaded a new update (v1.5) some weeks ago, but didn't got around to announce it, so it's still untested...
The main news is that I've tried to make it more cache-friendly for older CPUs with smaller caches.

From what I know, existing cache sizes include:

132Kbyte on Pentium III (what I had tested myself)
216Kbyte on 5x86
38Kbyte  on official Intel 486
42Kbyte  on older 486 clones
5None    on 386

The new mp3 decoder zip package includes a couple executables, it would be cool somebody could test if any of them is significantly faster, and which is fastest.
Most interesting would be test results for the lower-end CPUs with 8Kbyte or less cache.

The old decoder did only use each 2nd or 4th array entry for the /half and /quarter sample rates. The new decoder does instead use smaller arrays (which is much more cache-friendly).
The mp3wide.exe uses the old-sytle large arrays.
The mp3play.exe uses the newer smaller aarays.
What I am looking for are test results for below commandline switches:

1 mp3play  /test /half
2 mp3wide  /test /half
3 mp3play  /test /quarter
4 mp3wide  /test /quarter

And for the huffman lookup trees, the old version did process 9 bits at once, which requires lookup tables with 512 entries (which works best on my Pentium III with bigger cache).
The mp3huf1-9.exe files use 1..9 bits, with 32bit array entries.
The mp3huf1w-7w.exe files use 1..7 bits, and smaller 16bit array entries (which is much more cache-friendly, but needs a few more opcodes to untangle the data).

1 mp3huf1  /test
2 mp3huf2  /test
3 mp3huf3  /test
4 mp3huf4  /test
5 mp3huf5  /test
6 mp3huf6  /test
7 mp3huf7  /test
8 mp3huf8  /test
9 mp3huf9  /test
10 mp3huf1w /test
11 mp3huf2w /test
12 mp3huf3w /test
13 mp3huf4w /test
14 mp3huf5w /test
15 mp3huf6w /test
16 mp3huf7w /test

Rav wrote on 2024-09-26, 05:50:

I did test on my Cyrix 5x86 two times with a different set of CPU optional features.

Thanks! Good to know that you got similar speeds as ManyBothans, and even without the huge 1Mbyte cache, and even a bit faster (which, I guess that may be due to using DOS instead of Windows).

analog_programmer wrote on 2024-09-26, 06:12:

nocash wrote on 2024-09-26, 03:24:

Most decoders that can play a 44Khz 256kbit stereo mp3 file on a 486 at 100MHz with full quality should be also able to play the very same file at 33-40 MHz with reasonably good quality.

Which are those most decoders? And I mean an "OK quality" MP3 file (128kbit stereo) to be played on 486SX*/DX-40 CPUs.

I can't answer that. But let me ask back:
Do you believe that decoders can decode mp3 on 486-100 in full quality?
Do you know that most decoders have half/quarter/mono options for faster decoding?
Do you consider it legitimate to play high quality files in lower quality?

I've also started working on a mp3 ARM version for 16MHz Gameboy Advance. The first release is a bit too slow, but the next update will run very smoothly on that console.
And, I've got some very useful advice in nesdev forum: Instead of skipping samples in the output stage, one can also skip most of the data in input stage, which is making the low-quality decoding a whole lot faster.
With that, the next 80x86 update should work very well on 486-16, and with very low output-quality it might even work on 486-5 or 486-8, if those exist at all.
Which in turn means that it could be difficult to find a 386 that is too slow for mp3 decoding (or well, a 386SX could struggle with 32bit code, but might work better when porting the whole program to 16bit code).

How much need is there for a DOS version? When using the current win32 version, does the audio playback work with HXDOS on older PCs?

I have tried HXDOS on my Pentium III with onboard VIA sound chip. Running mp3play with /test switch is relative easy. But getting actual sound output without /test switch is more difficult (and the best I can get is random noise). What I've done is:

• Download the HXDOS Runtime and GUI package from the links at bottom of the HXDOS webpage.
• Boot win98 into DOS mode (either by not loading the windows GUI, or via Shut-Down, Restart in MS-DOS mode from inside windows).
• Copy the files from the BIN folder of each package into a directory that is inside of the PATH.
• Run HXLDR32, then run MP3PLAY with /test switch.

Easy. But for sound output there are more obstacles.

• HXDOS does require the SET BLASTER environment variable.
• HXDOS seems to require a SB Pro or newer (no SB 1 or SB 2).
• HXDOS doesn't support Ctrl+C (but Ctrl+Break does work).
• Real sound cards should work without further drivers (but with my VIA onboard sound hardware, I did need to run VIAUDIO, VIAFMTSR, VIAFMTSR /U, with results depending on whether I had booted directly into DOS, or rebooted into DOS from inside of windows).

Regardless, my sound hardware does only work with normal DOS software. With HXDOS it does merely produce noise during audio playback. I don't know if that's related to my sound hardware, or if the problem does also occur on other PCs.

Haven't there been older WinAMP versions that had a switch "Integer decoding"?