refactor: eliminate dead code and extract common patterns

[flexiondotorg]

Summary

This PR addresses three major refactoring objectives: modernising stdlib usage patterns, removing 14 instances of dead code that accumulated during development, and extracting repeated logic into shared helper functions across the codebase. The changes reduce code complexity, improve maintainability, and eliminate unused exports that cluttered the API surface.

Changes

• Replace unsafe.Pointer float32 conversions with math.Float32bits and math.Float32frombits from the standard library
• Use cmplx.Abs for complex number magnitude calculations instead of manual computation
• Remove dead code: SharedAudioBuffer (390 lines), ApplyHanning, WriteFrame, convertRGBToYUV, GetEncoderStatus, Frame.Release, AudioFlushProgress, 10 CLI style functions, and minor unused exports (net -1,306 lines)
• Extract audio buffer logic into buffer.go: FillFFTBuffer and ReadNextFrame helpers eliminate duplication in FFT analysis
• Extract FFmpeg boilerplate into ffmpeg_common.go: openAudioFormatCtx consolidates format context initialisation across decoder and analyser
• Extract renderer helpers into text.go: loadImageData, newTextDrawer, measureStringWidth, measureTextBounds eliminate duplication in asset loading and text measurement
• Extract standalone helpers: outputChannels(), writeRow/writeBarRow closures, and mustAnalyze test helper

Testing

• Existing test suite validates refactored code paths and buffer operations
• New tests in buffer_test.go cover extracted buffer helpers
• Audio analyser tests updated to use refactored patterns
• CI/CD pipeline confirms no functional regressions

[cubic-dev-ai]

2 issues found across 28 files

Confidence score: 3/5

• There is some merge risk: ReadNextFrame in cmd/jivefire/main.go now allocates per frame inside the render loop, which is a concrete performance regression from the prior no-allocation audio path.
• The test issue in internal/audio/buffer_test.go lowers confidence because TestReadNextFramePartialAtEOF may pass without proving partial-frame EOF behavior, so future regressions could slip through.
• Given the moderate severity and high confidence on both findings, this looks manageable but worth addressing before relying on performance-sensitive behavior.
• Pay close attention to cmd/jivefire/main.go and internal/audio/buffer_test.go - render-loop allocation regressions and incomplete EOF partial-read assertions are the main risk areas.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/audio/buffer_test.go">

<violation number="1" location="internal/audio/buffer_test.go:114">
P2: `TestReadNextFramePartialAtEOF` can pass without ever asserting that a partial frame was returned, so it may miss regressions in EOF partial-read behavior.</violation>
</file>

<file name="cmd/jivefire/main.go">

<violation number="1" location="cmd/jivefire/main.go:547">
P2: `ReadNextFrame` introduces per-frame slice allocations in the render loop, regressing the previous no-allocation audio read path.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: TestReadNextFramePartialAtEOF can pass without ever asserting that a partial frame was returned, so it may miss regressions in EOF partial-read behavior.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At internal/audio/buffer_test.go, line 114:

<comment>`TestReadNextFramePartialAtEOF` can pass without ever asserting that a partial frame was returned, so it may miss regressions in EOF partial-read behavior.</comment>

<file context>
@@ -0,0 +1,156 @@
+	// Drain most of the file
+	for {
+		samples, err := ReadNextFrame(reader, 4096)
+		if errors.Is(err, io.EOF) {
+			break
+		}
</file context>

[cubic-dev-ai]

P2: ReadNextFrame introduces per-frame slice allocations in the render loop, regressing the previous no-allocation audio read path.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At cmd/jivefire/main.go, line 547:

<comment>`ReadNextFrame` introduces per-frame slice allocations in the render loop, regressing the previous no-allocation audio read path.</comment>

<file context>
@@ -556,31 +544,15 @@ func runPass2(p *tea.Program, inputFile string, outputFile string, channels int,
-				cli.PrintError(fmt.Sprintf("error reading audio: %v", err))
-				p.Quit()
-				return
+		newSamples, readErr := audio.ReadNextFrame(reader, samplesPerFrame)
+		if readErr != nil {
+			if errors.Is(readErr, io.EOF) {
</file context>