Windows Media Player slow to load large m4b files (~30s+ for 400MB)

[KeinNiemand]

Currently the app uses Windows MediaPlayer (Windows Media Foundation) as the audio backend. For large m4b files
(tested with ~400MB), there's a significant loading delay (~30+ seconds) before audio playback begins.
This 30s freeze always occurs whenever you first start playback after launching the app then reoccurs every several minutes.

Initial Investigation

Manual testing with the same m4b file shows:

• Windows Media Player: ~30 second load time (same freeze reproduced in the native Windows Media Player app)
• VLC: Instant file open and playback ready

This suggests the bottleneck is in Windows Media Foundation itself, not the app's implementation. The file format
and size are valid — VLC's performance confirms the file is not the problem.

Proposed Solution:

Replace Windows MediaPlayer with LibVLCSharp to use VLC as the audio backend. This should eliminate the freeze since
VLC demonstrates nearly instant load times for the same files.

I have a newPlayer, currently it doesn't work at all yet, so it's not anywhere near ready for a PR but feel free to take a look.
One problem with with using LibVLCSharp is that the VideoLAN.LibVLC.Windows package only contains naitive libvlc binaries for x86 and x64 windows. To get ARM64 working it would be required to manually compile and package the ARM64 version of libvlc.

Either way fixing this 30s+ freeze is going to require replacing Windows Media Player, while LibVLCSharp seems like the best option to me there are probably other libraries that could work.

[KeinNiemand]

Ok my newPlayer branch now has VLC at least somewhat working, haven't done extensive enough testing if everything works nor do I take advantage of VLC native support for chapters in M4B files (in fact I turn it of explicitly right now), but at least it can play stuff now.

I'll probably make a clean version of my branch (without the dependency changes from #143) as a draft PR, even if everything works there still the ARM64 support problem to deal with.

[rstewa]

Now this is interesting because I have quite a few .m4b audiobooks that are greater than 400 mb and have not noticed this issue. Have you reproduced this with a different audiobook? Additionally, have you reproduced this on a different device?

[KeinNiemand]

I don't really have other .m4b audio books to test this with or well the only others I have now are part of the same series and bought from the same site and have the same problem.

I can replicate in fact replicate the problem on another device, at least the manual check of opening the .m4b manually in windows media player.

Maybe there just something weird with how these m4b are encoded specifically that windows media player can't properly handle?