JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

The AAC arm most conversions actually emit is the one audioArgs branch with no test #175

New Issue
Closed
opened 2026-09-02 02:15:13 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-02 02:15:13 +00:00 (Migrated from github.com)
Copy Link
Copy Source

The audio encoder most conversions actually use has no test

FFmpegCommandBuilder.audioArgs (app/src/main/java/org/libremediaconverter/ffmpeg/FFmpegCommandBuilder.kt:180-191).
Its FLAC, WAV/PCM and Opus arms have a test (flac wav and opus select the right encoders). The
default arm at :189 — listOf("-c:a", "aac", "-b:a", "192k") — has none:
grep -n '192k\|"aac"' app/src/test/java/org/libremediaconverter/ffmpeg/FFmpegCommandBuilderTest.kt
returns nothing, though MP4_H264 and friends are used throughout that file.

So the bitrate and codec that most conversions emit are unpinned: changing either passes.

Acceptance: the mutation that must go red

Change 192k to another bitrate, or aac to another encoder name.

Deliberately not in scope

An ENCODABLE_AUDIO-vs-audioArgs agreement test — the obvious-looking companion, mirroring
VideoCodecMimeAgreementTest. Do not add one here. It would freeze the answer to F1, which is
open and undecided: ContainerCapabilities.kt:84 says "nothing here emits a Vorbis encoder" and
FFmpegCommandBuilder.kt:188 does. docs/coverage-read-findings.md states in terms that the
tempting fix there locks in the wrong answer, and that the decision comes first. This ticket is the
AAC arm only.

## The audio encoder most conversions actually use has no test `FFmpegCommandBuilder.audioArgs` (`app/src/main/java/org/libremediaconverter/ffmpeg/FFmpegCommandBuilder.kt:180-191`). Its FLAC, WAV/PCM and Opus arms have a test (`flac wav and opus select the right encoders`). The default arm at `:189` — `listOf("-c:a", "aac", "-b:a", "192k")` — has none: `grep -n '192k\|"aac"' app/src/test/java/org/libremediaconverter/ffmpeg/FFmpegCommandBuilderTest.kt` returns nothing, though `MP4_H264` and friends are used throughout that file. So the bitrate and codec that most conversions emit are unpinned: changing either passes. ## Acceptance: the mutation that must go red Change `192k` to another bitrate, or `aac` to another encoder name. ## Deliberately not in scope An `ENCODABLE_AUDIO`-vs-`audioArgs` agreement test — the obvious-looking companion, mirroring `VideoCodecMimeAgreementTest`. **Do not add one here.** It would freeze the answer to F1, which is open and undecided: `ContainerCapabilities.kt:84` says "nothing here emits a Vorbis encoder" and `FFmpegCommandBuilder.kt:188` does. `docs/coverage-read-findings.md` states in terms that the tempting fix there locks in the wrong answer, and that the decision comes first. This ticket is the AAC arm only.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#175