Concerning file systems, there is a third one that comes with 3.1.4, and that is the CDFileSystem that reads CDRoms. The V45 version has almost nothing in common with the original CBM version. It is a close cousin of the Os 4 version, though, and borrowed many features from there. At the same time, it is both ahead and behind it, but the story is a bit complicated....
Similar to the FFS and CrossDos, it is multithreaded - which is a new feature. That is, if a CD-read is triggered, the file system remains responsive and can answer requests as long as the corresponding CD blocks are in cache. What the CD file system caches are administrative blocks, not data blocks. That is similar to the FFS. This multithreading is new, compared to both the Os 3.1 and the Os 4.0 version, and just a consistent new feature in all file systems.
It also supports the "DirectSCSI" flag. Regularly, the CDFileSystem attempts to read from the CD (or DVD) by means of CMD_READ. However, not all hostadapters support 2048 block sectors (as required) CD ROM data track access, and hence, this control flag turns out to be quite useful here as well. Previous solutions for the same problem used the "control" entry in the mount list, though details depended on the particular implementation.
Despite cache and multithreading, the CDFileSystem features a third mechanism to speed up accesses, and this is "read ahead". If a program does not attempt to read a large amount of blocks one after another, but is rather asking data block by block, this would imply that the CDRom has to start and stop reading, slowing down the transfer. The CDFileSystem instead now automatically loads block N+1 into cache when block N is read such that this access can then be satisfied quickly.
Multiple extensions made it into the 3.1.4 version compared to the 3.1 version: Joliet support (the proprietary "we don't read standards" standard from Microsoft for long file names), and Rock Ridge (the universally-accepted except on windows version for long file names), plus the Amiga-specific extension for protection flags (a proprietary, though popular and necessary extension). They all came in from the Os 4 version.
What also came in through Os 4 is support for audio tracks. That is, audio tracks appear as "AIFF" files on the CD file system and then can be played through MultiView, though an AIFF datatype (which, sorry to say, we did not include). Well, mostly Os 4, as there is more to say. Os 4 does not "read ahead" and "multithread" for audio, and unfortunately, there are about 30 different ways how to get audio data from a CD ROM (I love standards, you can select between so many of them). Os 4 had about support for three. The 3.1.4 version has a rather delicate algorithm to try them out, then stick to the one that worked, so you don't need to configure this in the mountlist.
What came also came in from Os 4 is support for UDF, which is the file format used by DVDs. It is a bit more modern than the ISO format, though UDF support includes caching, which it did not in Os 4, so it should hopefully perform better. Actually, UDF support was much more polished in the 3.1.4 version.
There are other things that did not make it into this version, though, simply because we run out of time, or haven't had material for testing. The Os 4 version also supports some simple video format (CDXA) but no support in the file system. Trouble is here lack of documentation, and lack of test material. There are multiple track formats a CD can be formatted in, not just 2048 byte sectors and 2352 audio blocks. It was - to me - completely unclear which format these disks take. As this is a rather exotic format, I decided to ditch it. As soon as I know more, I might reconsider, but so far nobody really complained.
The Os 4 variant also supported HFS and HFS+, the "we do make proprietary formats" format from Apple. Unfortunately, I don't have any fruit in the house, and neither test data to assess it, furthermore, the Os 4 code was depending on some GNU specific extensions to ANSI C such as function definitions within functions (today, one would probably call that "closures") which first had to be restructured to fit into ANSI-C to make it compile with SAS. Well, in the end, this looked all to risky, with no test data, and only a "best guess interpretation" what this GNU C should mean, so it was also ditched. It would have extended the work by probably another month, and this was hard to justify.
There are probably a couple of "strange" CD drives still alive in some machines that do not play by "any rule" (i.e. any formulated standard) that we may have forgotten, or for which we have no clear idea how to detect or support. For example, it is at least known that some (really old) CD drives return audio data as "big endian". While this sounds plausible on the Amiga, the MMC audio specs specifically require little endian, and thus the endian switch is always made. Of course, with rather bad side effects on such drivers that play in the wrong (or right?) order. As there at this time no clear guideline how to identify such ancient beasts, nor an idea how to drive them, there is no support for them either. If you have to happen such a thing, let me know, we probably find a solution. But, again, they probably all died out 10 years ago already...
There are also a couple of other tiny bugs here and there found during the review of the Os 4 code, so actually, overall code quality should have been improved - that, plus multithreading - should hopefully give you a rather stable and fast CD experience. It is actually more a "four file systems in one package" right now.
Just one word of warning: Do not expect CD audio to work on winUAE. It won't. The problem is that winUAE does not emulate MMC commands nor the CD-ROM TOC correctly, so no data comes through. That's not the fault of the CDFileSystem.