More accurate VBR durations

[DXCanas]

Bugfix

This PR attempts to fix two separate bugs I ran into, both (I believe) resulting from inaccurate audio duration estimations in AVFoundation:

1. Combine into Volume Misalignment: When computing chapters for bound books, inaccurate duration estimations from sub-files would stack, shifting chapter markers away from their true track boundaries.
2. Negative Scrubber Bug: When the actual audio stream outlasts the estimated duration, the GUI player time scrubber continues past the end, resulting in the remaining time ticking into the negatives.

I believe these bugs are direct consequences of Variable Bit Rate (VBR) encoding. This is unfortunate, as audiobooks are inherently well-suited to VBR and spectrum-based compression (given the relatively narrow frequency range of the spoken human voice).

Related tasks

• Closes Bug: ... In combined volumes, JumpToChapter does not nativate to the beginining of the specified chapter #1412
• Closes Bug: Lots of Extra Silence at the End of the File #1381

Approach

AVFoundation returns quick, estimated durations for stream-oriented formats (like MP3s or Ogg/Opus containers) when loaded via AVURLAsset without precise timing flags. This estimate is what gets baked into BookPlayer's CoreData store upon import.

This PR introduces targeted logic to explicitly pass AVURLAssetPreferPreciseDurationAndTimingKey: true during metadata extraction, library sync, and download verification.

To ensure we don't introduce performance regressions (i.e., slowing down imports) for formats that AVFoundation natively evaluates perfectly (like .m4a and .m4b), I gated this "precise" scanning is strictly gated behind an extension check. It only applies to .opus, .ogg, and .mp3 files.

Not as smart as checking for VBR encoding, but this seemed lighter touch.

These specific formats are structurally designed as continuous streams that can be appended to, meaning they lack a strict, reliable global duration header. While AVFoundation's default "quick-and-dirty" estimation based on file size and initial bitrate works perfectly fine on Constant Bit Rate (CBR) encoding, it can fail wildly for VBR (if it's using only a handful of samples to determine the bitrate of the entire file).

This would explain the variable "starts" described in one of the Volume import issues listed. I myself experienced that -- when moving to the next chapter, it would start at 30-110s after the start of the file.

Another thing I experience when using my VBR Opus files on a Volume-imported book: It would play to the end of the scrubber, then jump the next chapter at the incorrect time.

All in all, this made the "Volume" experience very difficult to use. But even outside of "Volume" mode, all the durations are wrong. including on the "Now Playing" screen. I'd regularly hit the end and watch the scrubber start counting in the opposite direction. Which was annoying but usable.

By requesting precise timing, we force AVFoundation to scan the stream. (Notably, web searches indicate that AVFoundation is smart enough to quickly detect if the file is actually CBR during this scan, meaning the performance penalty for CBR files should remain negligible).

Things to be aware of / Things to focus on

• The duration extraction for .opus, .ogg, and .mp3 files will now take slightly longer during import because AVFoundation is being forced to perform a full stream scan to determine exact duration for VBR files.
• However, since these extractions already occur asynchronously in the background (await), this should not block the main UI thread.
• Standard audiobook formats (.m4a, .m4b) are completely unaffected by this change and will experience no performance regressions.
• Full disclosure that much of this was authored by an LLM, though I, a human, was holding its hand throughout much of the planning and implementation.

[DXCanas]

Draft, as I am not very experienced in iOS development, and so need to configure my environment for proper testing unless someone else is willing to help me test :)

Thanks!