Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Back to the future: FLAC 1.4.2 for MS-DOS (Read 8726 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Back to the future: FLAC 1.4.2 for MS-DOS

Don't hold your breath for the build of FLAC nobody has been waiting for: FLAC for MS-DOS! Instead of fixing actual problems, I thought this would be fun to build. As the regular Windows build supports Windows versions from Windows XP and up, this build will be most useful for MS-DOS, Windows 95, 98 and ME, probably. Maybe Windows 2000 too. You can now decode 24-bit and 32-bit FLAC on systems featuring a 16-bit kernel! Hooray!

Below you'll find some answers to anticipated questions.

With whatever ancient software has this been build?
GCC 12.2.0 as modified by DJ Delorie, a.k.a. djgpp

Why? Seriously, why?
Just for fun. And for bragging rights. I saw there is a compile of FLAC 1.1.2 for MS-DOS here which is obviously very outdated (it cannot decode most 24-bit FLACs) and I saw an outdated mention of DOS support here so I felt like making a new build. Also, it is a showcase for the portability of the FLAC source code, because there were no changes to the source code necessary for this build. Same goes for Ogg, no changes were necessary there either.

Does it support UTF-8 filenames?
No, MS-DOS doesn't work with those. In other words, this build does not bring UTF-8 support to Windows 98 or similar. I'm not sure the latter is even possible, and if it is, it is probably a lot of work to get it right.

Can I get a DLL?
No, because MS-DOS doesn't have any form of dynamic linking as far as I'm aware.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #1 –
When I get time, I'll fire up my copy of MS DOS 6.22 to try it out. (I still have the floppies).  What does Flac output for the file extension?  .fla?  I don't remember if you could have file extensions with more than 3 characters back then.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #3 –
Wild. Now someone just needs to backport EAC 😂

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #4 –
Quote from: Porcus on
The HA mob demands performance tests!  :))

I still have a working AMD K6-III+ if we need period-accurate results!  I think it still has Win98 SE on it.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #5 –
I did functional testing in a Windows 98 VM, but that isn't a representative environment to do performance testing in, obviously.

DOSBox is a MS-DOS emulator specifically made for gaming. Those old games apparently heavily depended on the speed of the CPU to be constant as a 'timing source'. So, a faster CPU would mean a faster game. As the emulator has been crafted specifically to emulate old CPUs, not just in functionality but also for speed, I think timings here are valid. As I threw away all my hardware that old years ago, I don't have anything else to go on anyway.

DOSBox was set to normal emulation, running at 7800 cycles. According to this source, that should be close to a i386.

Anyway, I took a FLAC file from my collection: Nine Inch Nails - HYPERPOWER! from the album Year Zero. The track has a playback length of 102 seconds and is CDDA (stereo, 44.1kHz, 16-bit PCM).

Results
Decoding of file compressed with preset 0: 144s (0.71x realtime)
Decoding of file compressed with preset 8: 181s (0.56x realtime)
Re-encoding file with preset 0: 310s (0.33x realtime)
Re-encoding file with preset 8: 2515s (0.04x realtime)

As can be seen, a i386 is too slow to decode FLAC in realtime. A i486 or newer is probably fine though.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #6 –
Time to define a subsubset that decodes CDDA in realtime on i386 :P Verbatim+constant only, maybe a fast fixed predictor?

Why do I feel this should be whispered in hush tones:
Spoiler (click to show/hide)

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #7 –
Part of me is asking how fast FLAC (decoding) is compared to compress(1) or to its predecessor pack(1). pack is still supported by way of gzip (although support was broken for a few years without anyone noticing: https://www.vidarholen.net/contents/blog/?p=691 )

Part of me is asking me to stop asking such questions ...

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #8 –
Quote from: cid42 on
Time to define a subsubset that decodes CDDA in realtime on i386 :P Verbatim+constant only, maybe a fast fixed predictor?

Why do I feel this should be whispered in hush tones:
Spoiler (click to show/hide)
AMIGAAAH!  :D
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
Most common 14MHz 68020 or 7MHz 68000 might surely be not enough...

MPEG decoding used tricks like frame skipping to make video playback possible at all, wouldn't it be possible to simplify FLAC decoding, so only storage is lossless but actual playback lossy?

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #9 –
Quote from: rutra80 on
Is FLAC decoding slower than mp3?
FLAC is faster! At least on well-optimized compiles. The Rockbox gang would test this thoroughly: https://www.rockbox.org/wiki/CodecPerformanceComparison
Notice in particular how several of these players will downclock as much as they can (for battery life!), in which case the relevant figure in the respective table is the MHz number.

Say if you text-search for the first table done on an iPod Classic, then it would downclock to 8.05 MHz while decoding FLAC -8, while Lame at 96 kbit/s would need 20.47 (and Monkey's Extra High would need 220.47).
People would use FLAC over MP3 for extended battery life. Or well, at least they would use FLAC over MP3 for "I got more playback time than you have!". While Monkey's users - remember that not only CPU but also storage was expensive, so Monkey's had a heyday - would align themselves to what ape setting they could play back in real time.

8 MHz is ... not much! A mere 190 CPU cycles for each of the 88200 samples you need to get in place every second. As a Rockbox dev put it, you can decode a few FLAC samples by hand with pen and paper - and lo and behold, ktf & co do decode a couple of frames in the IETF draft spec: https://www.ietf.org/archive/id/draft-ietf-cellar-flac-07.html#name-first-audio-frame

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #10 –
Quote from: rutra80 on
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
My results are from an emulator, so I wouldn't be surprised if actual decoding speed is twice (or half) what I got. It is just a rough estimate.

In general, looking at the RockBox results Porcus linked, FLAC is about twice as fast as MP3 on these very low power ARM7, ARM9 and ARM11 CPUs. Could very well be numbers are very different on x86, or the instruction set that Motorola uses.

Looking at the results here one could extrapolate that reasonably modern superscalar, out-of-order x86_64 CPUs could decode FLAC with 7.5MHz or less. Wouldn't make any sense though.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #11 –
Quote from: rutra80 on
AMIGAAAH!  :D
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
Most common 14MHz 68020 or 7MHz 68000 might surely be not enough...
According to this:
Quote
Minimal configuration to play flacs realtime is 68030/50 - and some may still fail. Trying with lower lpc setting when encoding can help (lowering the replay frequency also does, of course).

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #12 –
What about WAV ?  It should even less demanding than flac

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #13 –
Sure. Uncompressed WAVE requires no "decoding" to produce the samples, they are there in order. 

For nitpickery, you might add: "presuming the appropriate endianness". Indeed, the reason for RIFF (over IFF) was that it was fit for little-endian. (And for even more nitpickery: the device needs to know signed vs unsigned.)

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #14 –
Resurrected the old 586 (socket 7) I built 22 years ago.  One of the memory sticks died and had to re-seat the GPU, but she still works! 

The CPU was released in April of 2000, and FLAC v0.5 (beta) was released about 9 months later.
 
Hardware:
CPU: AMD K6-III+ @ 550MHz
RAM: 128MB @100MHz
HDD: WD 40GB ATA100
OS: MS-DOS 7.1 (Win98)

Test Files (cdda/44.1/16):
The Fragile.flac - 1:43:48 (6228s)
Ghosts I.flac- 27:03 (1623s)
10 Miles High.flac - 5:14 (314s)

Seems as though the HDD is the bottleneck when decoding back to wave files.

10 Miles High:
-d = 13s
-0 = 11s
-1 = 14s
-2 = 16s
-3 = 26s
-4 = 35s
-5 = 48s
-6 = 81s
-7 = 100s
-8 = 165s

Ghosts I:
-d = 64s
-0 = 67s
-1 = 73s
-3 = 130s
-5 = 256s
-8 = 859s

The Fragile:
-d = 232s
-0 = 273s
-1 = 300s
-3 = 531s
-5 = 1005s
-8 = 3346s

USB 2.0 is quite a bit slower on this old machine than it is on modern machines.  Coping the files took a few minutes from my laptop to a USB 2.0 drive, but took almost 25 minutes to copy from the drive to the old machine.

10 Miles High (on the USB drive):
-d = 160s
-0 = 133s
-3 = 133s
-5 = 182s
-8 = 227s

I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #15 –
Those who have a 32-bit Windows 10, can find a 16-bit compatibility mode: https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/

Uh, and for those who want to run their nostalgia speed tests:
FLAC 0.7 for Windows is available at https://sourceforge.net/projects/flac/files/flac-win/flac-0.7-win
Beware that it requires output filename and no "-o". And that the presets are quite different, so you probably want to give full switches like -l 8 -m -r 6 -b 4608 (only multiples of 576!) to "compare" and find out how much faster new FLAC runs. (Around a factor of 4.5-ish on that setting here.)
And -8 was ... ooooh, slow. And there was a -9 for testing purposes (week-end testing I guess). Right now at this new computer I get it to run at 4.5 x realtime. (Yeah, two 4.5, no typo.)

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #16 –
Quote from: Replica9000 on
Resurrected the old 586 (socket 7) I built 22 years ago.  One of the memory sticks died and had to re-seat the GPU, but she still works! 

The CPU was released in April of 2000, and FLAC v0.5 (beta) was released about 9 months later.
 
Hardware:
CPU: AMD K6-III+ @ 550MHz
RAM: 128MB @100MHz
HDD: WD 40GB ATA100
OS: MS-DOS 7.1 (Win98)

Test Files (cdda/44.1/16):
The Fragile.flac - 1:43:48 (6228s)
Ghosts I.flac- 27:03 (1623s)
10 Miles High.flac - 5:14 (314s)

Seems as though the HDD is the bottleneck when decoding back to wave files.

10 Miles High:
-d = 13s
-0 = 11s
-1 = 14s
-2 = 16s
-3 = 26s
-4 = 35s
-5 = 48s
-6 = 81s
-7 = 100s
-8 = 165s

Ghosts I:
-d = 64s
-0 = 67s
-1 = 73s
-3 = 130s
-5 = 256s
-8 = 859s

The Fragile:
-d = 232s
-0 = 273s
-1 = 300s
-3 = 531s
-5 = 1005s
-8 = 3346s

USB 2.0 is quite a bit slower on this old machine than it is on modern machines.  Coping the files took a few minutes from my laptop to a USB 2.0 drive, but took almost 25 minutes to copy from the drive to the old machine.

10 Miles High (on the USB drive):
-d = 160s
-0 = 133s
-3 = 133s
-5 = 182s
-8 = 227s

I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...

That system with a socket 7 CPU should have zero problems playing FLACs.  I put together a socket 7 PC just last year.  Any x86 Windows machine from the mid to late 90's should be able to handle FLAC.  If it can run Windows 95 it'll probably handle FLAC fine (at least be able to play it).

I want to see a test with a CPU whose frequency is in the teens or twenties in terms of megahertz speed and something early 90's or late 80's.  Your 286 laptop sounds more interesting of the two to test.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #17 –
Quote from: Chibisteven on
That system with a socket 7 CPU should have zero problems playing FLACs.  I put together a socket 7 PC just last year.  Any x86 Windows machine from the mid to late 90's should be able to handle FLAC.  If it can run Windows 95 it'll probably handle FLAC fine (at least be able to play it).

I want to see a test with a CPU whose frequency is in the teens or twenties in terms of megahertz speed and something early 90's or late 80's.  Your 286 laptop sounds more interesting of the two to test.

I'm not sure what size HDD is in the 286 laptop.  I think it's 30MB.  If I remember correctly, DOS and Win 3.1 only take up 6-7MB.  So I could only test with a small wave file, maybe 15MB.  I also think the only way I'm going to be able to transfer files is via floppy disk.  Maybe split and combine them after transfer, unless a ~1.44MB wave file is enough for a test. 

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #18 –
Quote from: Replica9000 on
Seems as though the HDD is the bottleneck when decoding back to wave files.
You can use flac -t instead of flac -d to check. That way it fully decodes but doesn't write anything.

Quote
I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...
This won't run on a 286. That is 16-bit, and this compile needs at least 32-bit to work. So, bare minimum is i386 with 80387 coprocessor.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #19 –
Oh. So you need a 32-bit architecture, but then it works on a 16-bit OS?
Is 32-bit bus needed? Asking for all those 386SXes around. I know of at least one in daily use, you don't want a crash report from them.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #20 –
Bus width doesn't matter, it will work on a 386SX. (Assuming you have a 387SX to go with it, of course.)

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #21 –
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

Apparently, MS-DOS worked fine on 16-bit CPUs like the Intel 8086. However, the Intel 80386, while preserving backward compatibility, added 32-bit capabilities. With the much more recent switch from 32-bit to 64-bit, you need a 64-bit OS to enjoy the benefits of a 64-bit CPU, but apparently, back in the day, it was possible to use 32-bit capabilities on a 16-bit OS. Windows OS before 95 (and not the NT variants) would run on 16-bit only, but capabilities were limited: 80286 processor for standard mode, 80386 or higher for enhanced mode

This worked with so-called DOS extenders. There were 16-bit DOS extenders that only extended memory addressing, but much more common were 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit. FLAC uses 64-bit arithmetic, which can be reasonably emulated with 32-bit but not so much with 16-bit. Also, even if FLAC were stripped of 64-bit arithmetic, it would be much slower.

Anyway, the compiler suite I build this with, djgpp, targets "32-bit extended MS-DOS". That means i386 minimum. Also, FLAC has a build option to disable the use of floating point instructions, but then the encoder can only encode fixed subframes, so presets 3 through 8 become useless. Decoder is unaffected by the way. However, I didn't use this build option, so an FPU is needed, which means the i386 will need an 80387 coprocessor, as it doesn't have a built-in FPU like we are used to these days.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #22 –
Ah, floating-point on Pentium![note] https://en.wikipedia.org/wiki/Pentium_FDIV_bug

The most powerful of the first-release Pentium was the Pentium 66 running at, apparently, closer to 67 MHz than 66.
There must have been 66.6 jokes around already then - all those sources who tell you about "Satan Inside" after the FDIV bug cannot all be conveniently backdating it a few years from the Pentium III 667, can they?  :-X





[note] OK, to those who don't know FLAC internals: FLAC does not depend on floating-point math being "correct".
FLAC works by creating a "predictor" to "coarsly approximate" the signal, and because it has to be lossless in the end, it also has to encode the difference between signal and predictor ("residual").
A better predictor leads to better compression. A worse predictor leads to worse compression. Buggy floating-point math will at worst give you a worse predictor, because once a (good or bad) predictor is found, the rest of the encoding is done "in integer math".

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #23 –
The laptop is a no go anyway.  The HDD is dead and it won't boot from floppy.  The only thing I have between the 286 and my K6-III+ is a Pentium 233 chip (that'll work on the same board as the K6-III+).  It's configured by jumpers so the lowest I can run it at is ~133MHz which should still be able to play Flac files just fine.
 

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #24 –
Quote from: ktf on
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

[...] 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit.
Well, thanks for making me feel old. A DOS extender is only necessary for 32-bit addressing; it's possible to do 32-bit arithmetic without one.

Quote from: ktf on
However, I didn't use this build option, so an FPU is needed, which means the i386 will need an 80387 coprocessor, as it doesn't have a built-in FPU like we are used to these days.
Somehow I forgot this when I posted earlier (must be getting old  :)) ), but DOS extenders can include FPU emulators, so you might not need a FPU.