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"?

Hi, I just found this interesting project. It seems a lot of optimization was done. I tested it on my Tx486DLC in 386MB (this system: http://rayer.g6.cz/hardware/retropc2.htm#386DX_PGA_MOD ).

1st I tried minimp3 decoder in C, compiled for DOS by myself.
A 16s sample of mp3 128kbit/44k was decoded in 100s - oh, no way.

Then I tried your mp3play 1.5 and it do much better,
full quality decoded in 23s - getting closer
/half - 13s - more than realtime!
/quarter - 9s - even better.
Now I have to install some soundcard to check real playback (have just bare w95osr2 installed, no drivers yet, 16MB RAM seems be enough).

I also tried to run it under HXDOS but always got crashed (terminate dpmi client/server)

I saved some logs, I paste it later...

Will try on my 40MHz Am386DX system with 8MB RAM, Cyrix coprocessor and at least 64K cache. I'm having trouble with 128K cache.

It's optimized to integer / fixed point math, no FPU used/needed...

Cool, I installed SB AWE64 and can play 128-320kbit MP3 on 486DLC @40MHz with /mono or /half option with good safe margin.
I'll test also on Am386DX-40 soon.

It turned out that Am386DX-40 is significantly slower than Tx486DLC-40 for MP3 decoding (16s sample):
full Q: 37,602ms vs 22,933ms
22kHz: 22,370ms vs 13,075ms (/half)
11kHz: 16,178ms vs 9,228ms (/quarter)

Even with more tuning when got at best to 15,5s it has some random dropouts so I need to go with 22kHz mono: 11,466ms (/half /mono) got safe margin enough for smooth playback and still sounds good. I made a video:

https://www.youtube.com/watch?v=7DuXoMHgSDo

And here I found some turkish guy who rewrote mp3play for hos own 32bit TRDOS (so he avoided widows 😀
https://www.youtube.com/watch?v=GoGeS4ul2nw

Here are colleceted log files and sample 16s MP3 fragment 128kbps/44k/strereo that I tested it with...

RayeR wrote on 2025-03-15, 07:30:

And here I found some turkish guy who rewrote mp3play for hos own 32bit TRDOS (so he avoided widows 😀
https://www.youtube.com/watch?v=GoGeS4ul2nw

Thanks for mentioning this port. As expected it's for some DIY turkish "real DOS" and completely incompatible with normal variants of "disk operating system". I've tried those x86 MP3PLAYx.PRG executables renamed to .COM (obviously they're not in MZ-format) with no success. Next option is if it's possible to recompile with TASM or FASM compiler for DOS executable, which is compatible with m$-DOS.

It would need to add some SB16 driver/library first, it cannot be ported as is because it use some sound API call instead of direct access.

Playstation version is coming next. I have finally started porting the ARM code to MIPS, that are about 34,000 lines of source code, and after 15 days of non-stop coding, I have got it working to play a mp3 with intact audible sound.

The various log files are also showing the same numbers for initialization tables, frame headers, and dct values in both ARM and MIPS versions. And with an extra day of coding, the mp1/mp2/wav/aiff/au functions are also fully ported (albeit untested), and flac decoding is also nearly fully ported.

Performance is also looking fine from initial tests. The PSX has twice as many MHz as GBA, but the Multiplier and RAM is slower, so I had expected GBA and PSX to be reaching roughly the same speed. At the moment the PSX does even look a little bit faster - which is surprising because I haven't even used its data cache (or scratchpad memory) yet.

There are still a dozen of things that need to be done before releasing the PSX version: CDROM loading, audio sync, GUI glitches, testing, and supporting extras like mouse, analog pads, memory cards, reverb, search/keyboard input, etc.

RayeR wrote on 2025-03-16, 01:30:

Here are colleceted log files and sample 16s MP3 fragment 128kbps/44k/strereo that I tested it with...

Thanks! After finishing the PSX version, I am quite tempted to port the GUI from the ARM/MIPS back to 80x86, and try to make a DOS version for 80386/80486.

The 128kbps test file makes it difficult to compare against the other test results. 128kbits is more lightweight than the pisse/fliegerbombe song, and it looks as if that 128kbits file isn't even using any sounds in the higher frequency range, which would make it even more lightweight.

Oh, and by the way, the ARM version for GBA/NDS/DSi/3DS has been finished a while ago. I am quite fond of the GUI - the filelist, playqueue, search, options, help windows are probably a bit easier to use than the commandline switches in the x86 version.

Audio sync is working now. That was difficult, and it's really important to make sure that unused audio channels aren't simply muted, but also configured to loop dummy samples (otherwise the unused channels will still trigger unexpected audio IRQs on random memory fetches).

Still missing are adjusting the GUI colors for currently selected lines/tabs. And CDROM loading and streaming.

In the VCD player (an older PSX project) I had used the reverb buffer to output uncompressed PCM samples at 22kHz, but that won't work well when using mp3/flac/wav/etc files that aren't using a multiple of 11kHz (and it would somewhat prevent using reverb for actual reverb/echo/hall effects).

So this time, I am using two uncompressed 4bit ADPCM channels to produce 8bit PCM output, which seems to be working quite well. A small problem is that the 4bit values are signed, producing unwanted carry-outs from LSB to MSB (one can compensate that by adjusting the MSB, except not for the loudest positive values in range 78h..7Fh). The other option would be to use only unsigned 3bit values as LSBs, like 4+3bit = 7bit, or 4+3+3bit = 10bit, etc.