fix(transcription): accept WhatsApp .opus voice notes in file transcription - #866
fix(transcription): accept WhatsApp .opus voice notes in file transcription#866juanmartitegui wants to merge 1 commit into
Conversation
WhatsApp voice notes are Ogg Opus files with a .opus extension. macOS maps .opus and .oga to the same UTType as .ogg (org.xiph.ogg-audio) and decodes them natively, but supportedFileExtensions was built from each UTType's single preferredFilenameExtension, dropping every alternate extension tag — so dropping a WhatsApp .opus file was rejected as unsupported even though the decoder fully supports it. Build the set from every filenameExtension tag of each decodable audio/video UTType instead, and mention OPUS in the user-facing copy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The PR Policy check is blocking this PR because required template information is missing. Please update the PR description with:
Screenshots or video are required for UI, UX, settings, onboarding, overlay, menu bar, or visual behavior changes. If this PR has no visual changes, check the no-visual-change box in the template. If this remains incomplete for 48 hours after opening, the PR may be closed. |
Greptile SummaryThe PR broadens file-transcription extension detection to include every filename-extension tag exposed by AVFoundation-backed audio and movie UTTypes, allowing WhatsApp
|
Description
Drag-and-dropping a WhatsApp voice note (
.opus) onto the file-transcription drop zone shows "Accepted file types…" and rejects the file, even though macOS decodes Ogg Opus natively.Root cause:
MeetingTranscriptionService.supportedFileExtensionsis built fromAVURLAsset.audiovisualTypes(), but only keeps each UTType's singlepreferredFilenameExtension. The Ogg audio type (org.xiph.ogg-audio) declares the extension tags["ogg", "oga", "opus"]withoggas preferred, so.opusand.ogawere dropped from the accepted set while the decoder fully supports them (verified with a real WhatsApp.opusfile:AVAudioFile/AVAssetread it fine — mono, 48 kHz, 24 s).Fix: build the set from every
filenameExtensiontag of each decodable audio/video UTType instead of just the preferred one, and mention OPUS in the supported-formats copy. No transcoding or special-casing needed — the existing pipeline handles the file once the extension check stops rejecting it. Every previously accepted extension is still accepted (verified: old set ⊆ new set); the set still derives only from what AVFoundation reports as decodable, so subtitles/playlists remain excluded.Type of Change
Related Issue or Discussion
Closes #868
Testing
swiftlint --strict --config .swiftlint.yml Sources(not installed locally — relying on CI)swiftformat --config .swiftformat Sources(not installed locally — relying on CI)SupportedFileExtensionsTests(regression:.opus/.ogaaccepted, common formats kept, non-audio types still excluded). Local machine has no full Xcode, so XCTest runs in CI; the exact old-vs-new set logic was verified locally with a standalone Swift script against AVFoundation, and the real WhatsApp.opusfile was verified decodable viaAVAudioFile/AVAsset.Screenshots / Video
No layout or visual behavior changes. For full transparency, the supported-formats caption/error string constant gains one word:
before — "Supported: WAV, MP3, M4A, OGG, MP4, MOV, and more"
after — "Supported: WAV, MP3, M4A, OGG, OPUS, MP4, MOV, and more"
Notes
UTType.tags[.filenameExtension]also picks up other alternate extensions macOS already decodes (.wave,.bwf,.aif,.mpeg,.m2ts,.3gpp, …), which is strictly more permissive but still bounded byAVURLAsset.audiovisualTypes()— i.e. only formats the OS decoder claims to support.🤖 Generated with Claude Code