Question Compress video to fit on 1.44 MB floppy disk

ragnarok0274

Proper
Sep 12, 2020
177
9
115
5
I discovered a project from February where I was trying to fit a video onto a 1.44 MB 3.5" floppy disk.
According to the note in the folder, I was compressing the first PewDiePie video I ever watched to fit it onto a floppy disk for LWIAY.
So far I have gotten it to 4.8 MB as an MP4 file.
Any advice/ideas?
Constraints:
Must retain original aspect ratio (16x9)
Must contain both audio and video
Must still have color (this can be omitted if this will make it fit, but otherwise no B&W)
Must be the same length, so no removing video
Must not be put into an archive
Must not be put on 2.88 MB floppy disks.

Once this is done, the second part begins.

EDIT:
Forgot to say which video.
The Cool Cat Cringe Tuesdays video.
Don't ask, because I don't know.
 

ragnarok0274

Proper
Sep 12, 2020
177
9
115
5
Question about DMF:
If I use a USB to 34-pin floppy converter, will it still read or no?
Auto-compressing doesn't do anything anymore, too - I think the only thing left is to manually squeeze more data out of it somehow.
 

ragnarok0274

Proper
Sep 12, 2020
177
9
115
5
I will try it then once my part comes in from China.
Darn you, COVID, for making my "legacy tech"-"modern tech" converters from China take so long!
 

USAFRet

Titan
Moderator
Mar 16, 2013
139,826
7,561
173,940
21,479
I discovered a project from February where I was trying to fit a video onto a 1.44 MB 3.5" floppy disk.
According to the note in the folder, I was compressing the first PewDiePie video I ever watched to fit it onto a floppy disk for LWIAY.
So far I have gotten it to 4.8 MB as an MP4 file.
Throw out 3 of every 4 frames.

or

reduce to 16 colors, and throw out 2 of every 4 frames.
 

jasonf2

Honorable
Oct 11, 2015
342
88
10,890
21
Also not to be a downer but the 3.5" floppy drive held ~1.44mb but the read write speeds were like 500,000 bps (roughly 62.5kBps before overhead) constant speed devices. I am not sure that you are even going to even be able to play your high compression video without massive lag without copying it back to a modern drive. Also you had better make backups because fail rate was terrible. Go for a squeeze wmv codec/format. If it won't fit nothing probably will.
 
Last edited:
Also not to be a downer but the 3.5" floppy drive held ~1.44mb but the read write speeds were like 500,000 bps (roughly 62.5kBps before overhead) constant speed devices. I am not sure that you are even going to even be able to play your high compression video without massive lag without copying it back to a modern drive. Also you had better make backups because fail rate was terrible.
The video runs for 22 minutes. This means that the user needs to be able to read and buffer the floppy diskette in 22 minutes or less.

The effective data rate is 1117 bytes per second.
 

ragnarok0274

Proper
Sep 12, 2020
177
9
115
5
I'm comparing thread helpfulness currently.
And I don't care about stuttering and/or quality. It just needs to fit.
Why:
Needed a new project and LWIAY.
 

jasonf2

Honorable
Oct 11, 2015
342
88
10,890
21
USAFRet is right. Simple compression codecs alone are not going to get the video down to the required size. You will have to remove significant amounts of frame data to make the file size low enough. By the time you make it down that far I don't know how much fidelity (video or audio) you will have left, but it will be interesting. My guess is something closer to a really bad animated gif than a video. I don't miss floppies, either the 5.25 or 3.5. They defined the need for a "working copy".
 
Simple compression codecs alone are not going to get the video down to the required size. You will have to remove significant amounts of frame data to make the file size low enough.
Yes they are, if you provide the maximum allowed bitrate they will butcher the video as much as they have to automatically.
The problem is that there is not enough space for both video and audio of a 22 min video to get anything even resembling the worst thing you have ever seen.
Using
x264.exe --bitrate 6 --vf resize:32,18 -o d:\test.mkv d:\original.mp4
I get a 1.2 Mb video file, that's 32 by 18 pixels and it only has video.
Turning the audio into the smallest possible with
ffmpeg.exe -i d:\why.mp4 -ab 1k -ar 8000 -vn d:\out.mp3
Is another 1.3Mb

These are the smallest settings that provide files that can still be played back by modern players.

You can reduce the video by going down to 1 bit and get a B&W shadowy soup of pixels of 868K size but I don't know of any way to make compliant audio files with less than 1k bitrate.
 
Also not to be a downer but the 3.5" floppy drive held ~1.44mb but the read write speeds were like 500,000 bps (roughly 62.5kBps before overhead) constant speed devices. I am not sure that you are even going to even be able to play your high compression video without massive lag without copying it back to a modern drive. Also you had better make backups because fail rate was terrible. Go for a squeeze wmv codec/format. If it won't fit nothing probably will.
That's why God invented caching...
 

jasonf2

Honorable
Oct 11, 2015
342
88
10,890
21
Yes they are, if you provide the maximum allowed bitrate they will butcher the video as much as they have to automatically.
The problem is that there is not enough space for both video and audio of a 22 min video to get anything even resembling the worst thing you have ever seen.
Using
x264.exe --bitrate 6 --vf resize:32,18 -o d:\test.mkv d:\original.mp4
I get a 1.2 Mb video file, that's 32 by 18 pixels and it only has video.
Turning the audio into the smallest possible with
ffmpeg.exe -i d:\why.mp4 -ab 1k -ar 8000 -vn d:\out.mp3
Is another 1.3Mb

These are the smallest settings that provide files that can still be played back by modern players.

You can reduce the video by going down to 1 bit and get a B&W shadowy soup of pixels of 868K size but I don't know of any way to make compliant audio files with less than 1k bitrate.
I am sorry, but I think you just supported what I said rather than rebutted it. Let me see if I can play back what you just said. You can make a 22 minute long black blob movie that doesn't even markedly resemble the original video with no audio. But if you have to add audio it will double the file size and it won't fit? I think that qualifies my statement pretty well. Without getting too technical codec compression is all about generalization. It is easier to explain a single frame instance like RAW vs JPEG. A RAW image records on a single pixel level all of the available information. So depending on bit depth and pixel count a single image can get massive. Because a RAW image is on a per pixel basis however it is the best possible fidelity of the image. JPEG (or any compression format) generalizes. If I took a picture of a sky in RAW the subtle variations of the blue in the sky would be recorded on a per pixel basis. In a compression format however fields of blue are generalized. In a higher quality compression many fields are established and fidelity loss is pretty minimal. In a extremely low quality compression though you might just end up with a single shade blue square because you have over generalized. So the more you compress, the more fidelity you lose until you literally compress the image to a point that it is no longer even resembles the original content. Even so there is still an overhead necessary to define the field data that will actually overrun the image once reduced to single bit levels so there is a base bitrate even with no content. Video with audio is even worse because you have to sync the audio and video together.

As to your caching comment today the ability to literally load the entire contents of the disk into RAM is a joke at 1.44mb, but back in the day when we were actually using floppies 640k of RAM was pretty standard and you had a kick butt machine if you had another 1024 extended on top of the base 640k . By the time your OS was loaded (often from your floppy drive into RAM) there wasn't much left depending on the drivers you were bootstrapping. If the point to this whole thing is some throwback legacy thing even plugging the drive into anything over an 80486 or early Pentium makes the whole thing pointless. Lets get real with this and try it out on an 8086 or a 286 class which could not even render realistic video. Even with a Pentium 3 (that was well into cdrom days (640mb) your modern compression algorithms would have absolutely no chance of running on that hardware anyways.
 

ragnarok0274

Proper
Sep 12, 2020
177
9
115
5
This is for LWIAY*. I have a 3.5" floppy drive + 34-pin to USB adapter in my Windows 10 machine, and am going to play it off of that.
I will then compare the original video to this and label it "The lowest quality PewDiePie video ever - from 2020".
*and to finish an abandoned project so I can get back that ~2GB of Google Drive space.
And I do have a Pentium III.
Slot 1, 500 MHz with 1 GB of RAM.
 

jasonf2

Honorable
Oct 11, 2015
342
88
10,890
21
I am sorry but if you do the simple math at 1.44 megabytes on that floppy and 1320 seconds of play time the math doesn't add up. 1.44*1024= 1475K (That is assuming that the FAT isn't eating into the formatted size, it has been too long to remember what the formatted size of a 3.5 was and we used to use fat tables that were significantly smaller than exfat, fat32 or NTFS so the number today, formatted on a win10 machine would be smaller.). So with 1475K and 1320 seconds we would get 1.1171 KBps. With that bitrate you aren't going to get discernable audio, let alone synced video even with the best compression codecs available. That bitrate wouldn't even be valid for a bad VOIP call (Audio). Although if life has taught me anything if you hack at something long enough you will get some result, although not always what you want, so have fun with it!
 
I am sorry but if you do the simple math at 1.44 megabytes on that floppy and 1320 seconds of play time the math doesn't add up. 1.44*1024= 1475K (That is assuming that the FAT isn't eating into the formatted size,
The actual formatted capacity of a standard "1.44MB" diskette is neither 1.44MB nor 1.44MiB. It's actually a misnomer.

80 tracks per side x 18 sectors per track x 2 sides x 512 bytes per sector = 1440 x 1024 bytes.

That's 1440 KiB or 1.47MB or 1.41MiB.

A standard FAT12 volume has two FATs, but I suppose one could reduce this to a single FAT with an appropriate tool.
 

jasonf2

Honorable
Oct 11, 2015
342
88
10,890
21
The actual formatted capacity of a standard "1.44MB" diskette is neither 1.44MB nor 1.44MiB. It's actually a misnomer.

80 tracks per side x 18 sectors per track x 2 sides x 512 bytes per sector = 1440 x 1024 bytes.

That's 1440 KiB or 1.47MB or 1.41MiB.

A standard FAT12 volume has two FATs, but I suppose one could reduce this to a single FAT with an appropriate tool.
As said before, it has been too long since I formatted one. But fat8 was the preferable format if memory serves (to conserve size). I don't know if Win10 would even read a disk formatted in FAT8 and I am pretty sure it won't format to it. I don't remember fat12, I thought it jumped to straight to fat16 as drives started getting bigger. Get out your working copies of MSDOS and lets have a throwback hardware party.... Oh yea, config.sys, autoexec.bat, manual bootloader drivers and jumper settings made us nerds relevant because no one else could get anything to run. Or lets not, lol.
 

ASK THE COMMUNITY