Mp3FileReader slow performance when opening a large file located on a network share

[Peter Jarrett]

We have found an issue with opening a very large (>1hour long) mp3 file that is stored on a remote network share,

This is running our application on Windows 10 Pro, accessing a file stored on Windows Server 2019 network share over a 1Gbit network. Copying the file using basic file copy commands copies it at around 700mbit/sec, so we know that network performance is good.

We believe the issue is that during the initial open of the file, the call to CreateTableOfContents reads the entire file to build the table of contents, and over the network that can be very slow.

Am I correct that the purpose of the CreateTableOfContents is to build the tableOfContents (TOC) and that is ONLY used during a seek operation caused by calling the set of the Position property? I presume this is to allow for VBR files which make it impossible to easily seek around in the file to a desired time position?

If so, would there be scope to alter the process so that when first opening the file, only the first few seconds of the file are seeded into the TOC list, and then ONLY if the application calls for a position change would more of the file be read to determine the correct frame to seek to.

That could perhaps also be intelligent enough so that it only reads enough of the file until you find the frame you need at which point it stops seeking and building more of the TOC. This does mean that seeking further and further FORWARDS through the file would mean slower progressive seeking as it discovers and caches more frame locations, but any seek backwards would still benefit from the TOC, and future seek forwards would ALSO still benefit as long as it's to areas within the TOC.

Note: If you use the MediaFoundationReader this issue doesn't happen, but we have found that you HAVE to use the MF reader from the main UI thread due to the internals of the mf reader, and we ideally need to use the ability to run from multiple threads that the mp3FileReader gives us.

If anyone has any other way we could tackle/bypass the performance issue of reading the TOC for very large files that would be great.

[Mark Heath]

Yes, the TOC building is a known performance limitation of Mp3FileReader, and the reason I recommend people use MediaFoundationReader wherever possible. Progressive TOC building would be great for Mp3FileReader to have in the future, but it is a fairly significant development effort. It should be possible to work around the threading issues with MediaFoundationReader.