[hemanpapa-coder]

Adds an experimental stereo-linked texture processor after Apollo inference, controlled by --texture-reduction-db (0–3 dB, default 0/off). It reuses the existing Apollo prediction without changing weights or adding model forwards.
Scope
The diff now contains only the processor, CLI integration, two relevant test files, concise documentation, and the SciPy test dependency in the CPU workflow (6 files). The full enhancement chain and larger evaluation materials remain separate in the fork’s fixed experimental history and existing Releases. The reduction is a follow-up commit; prior history is preserved.
Enabled processing checks optional SciPy before audio/checkpoint loading and rejects inputs shorter than 2048 frames before checkpoint/model loading. The disabled path retains its optional-dependency bypass and short-input behavior.
Texture-only comparison
Comparison bundle and source information:
https://github.com/hemanpapa-coder/Apollo/releases/tag/texture-evaluation-20261016
Detailed report:
https://github.com/hemanpapa-coder/Apollo/blob/f160a8a1e267626da2136fc20a487eef99f8cf28/evaluation/texture-20261016/REPORT.md
Eight aligned 15-second excerpts include source-proxy/degraded/Apollo 0/1/2/3 dB WAVs and loudness-matched blind copies, quiet material, two no-added-degradation controls and adverse examples. All caps use the same upstream Apollo prediction. The existing bundle’s 120 file hashes were verified; all 24 enabled excerpt outputs were reproduced exactly on CPU. No new model inference was needed.
Validation and limitations
The reduced tree passed 33 local CPU tests. CLI model loading is mocked; these tests do not establish pretrained-checkpoint or perceptual quality.
Pinned Linux CPU CI on submission head 14b9e53 passed all 33 tests in the fork:
https://github.com/hemanpapa-coder/Apollo/actions/runs/39392480837
Upstream CI on the same head awaits maintainer approval, not a completed test pass:
https://github.com/JusperLee/Apollo/actions/runs/39392483200
This heuristic can suppress wanted detail, modulation and transients; it is not an artifact detector. Full-output STFT memory remains O(duration). The historical 180-second repeated-prediction probe required 2328.58 MiB tracked peak / 3042.25 MiB process RSS, excluding the model; this is not full-song listening validation. Sources are lossy proxies, not lossless clean-master references. No controlled listening result or universal quality improvement is claimed.
Keeping Draft for texture-only listening and maintainer evaluation. Upstream attribution and the repository CC BY-SA 4.0 license are retained; audio has its separately documented source licenses.

[JusperLee]

Thanks for the contribution. The opt-in integration and explicit limitations are useful, and I reproduced all 30 unit tests locally. I would keep this as a draft until we can evaluate it on real Apollo outputs.

Could you provide 6–8 publicly shareable, aligned 10–20 second music excerpts covering vocals/sibilants, piano or plucked strings, drums/cymbals, dense mixtures, and quiet material? Please include examples that already sound clean without post-processing, plus at least one unsuccessful or adverse case.

For each excerpt, please provide the degraded input, current upstream Apollo output with post-processing disabled, and that exact output processed at 1/2/3 dB. Include a clean reference where available. Keep the checkpoint, upstream commit, device, and chunk/padding settings fixed and publish the exact commands and input provenance. Please provide both raw WAVs and consistently loudness-matched blind audition copies with common peak headroom, and identify the timestamps where the effect is intended to help.

The synthetic benchmark is reproducible, but it does not involve Apollo inference and cannot establish whether suppressing these spectral excursions improves restoration or removes wanted musical detail.

Two implementation issues should also be addressed:

• Check the optional SciPy dependency before loading/running the model. Minimal/macOS inference dependencies do not include it; currently inference completes and then fails on import without saving the result.
• Handle or reject outputs shorter than 2048 frames before model loading. A 1024-frame input runs with the same Apollo architecture when the option is disabled, but enabling it raises only after the forward pass and produces no output. The minimum is documented; the CLI should enforce it earlier or define an explicit short-clip bypass.

Please also include representative song-length memory measurements. In my local allocation probe, 30 seconds of 44.1 kHz stereo required about 318 MiB of peak tracked allocations for the post-process, excluding the model. This is an acknowledged design limitation, but important for chunked-inference users.

The current GitHub Actions run is marked action_required, so we also need a completed successful CI run. My local test environment differs from the pinned CI versions; I have not validated a pretrained checkpoint or performed controlled listening.

[hemanpapa-coder]

Thanks for the detailed review. Both early-validation issues are fixed in de57e73, with regression tests proving failure before checkpoint/model loading and preserving the disabled short-input path.

The updated PR includes an eight-excerpt real Apollo review bundle and report/data: 15-second raw WAV comparisons at 0/1/2/3 dB, randomized loudness-matched audition copies, credits/hashes/settings, and inspection timestamps. Source files are already lossy, so there is no clean-master reference. Two no-added-degradation controls and objective adverse examples are retained; neither artifact-free controls nor perceptual improvement is claimed.

Song-length post-process memory remains high: the 180-second probe repeating actual Apollo output measured 2328.6 MiB tracked allocations / 3042.2 MiB process RSS, model excluded. This limitation is documented, not fixed.

CI on final head 4a89524 passed all 33 tests. The upstream run still requires maintainer approval. The uploaded ZIP size and server SHA-256 match the locally CRC-verified archive. Keeping this Draft for listening and your evaluation.

[hemanpapa-coder]

Added a Suno-specific public comparison bundle and updated the PR description. The creator supplied Untitled1017.wav and explicitly authorized public distribution.

This is a 218.36-second Suno song processed directly without added codec degradation (48→44.1 kHz resampling). The fixed upstream model/settings were used once for the full song; that exact prediction is processed at 1/2/3 dB. The bundle includes full-length versions, eight aligned 15-second raw/blind excerpts, an HTML audition page, five aligned comparison tracks in a REAPER session, reproduction instructions, measurements and hashes. All eight blind groups pass <0.000001 LU spread and <= -1 dBFS oversampled-peak checks.

This supplements the earlier CC-recording set with the intended Suno use case. It is one song, not eight independent examples; there is no clean reference or controlled listening verdict, and the generated REAPER session has not been tested in a live DAW. Code is unchanged from 4a89524, with the existing 33-test fork CI result. Keeping Draft for listening and maintainer evaluation.

ZIP SHA-256: 90592aedd3b599ea94a862b17bf28c05456f603bb29df57a053d35eb7419945b (789188701 bytes).

[hemanpapa-coder]

Completed the creator-authorized full-song application comparison: all 25 windows / 218.36 s. Download the new ZIP and open enhanced-full/index.html; input/upstream/full-chain WAVs are aligned and matched to -23 LUFS, with a generated three-track REAPER session, raw enhancement, source/runtime hashes and numerical reports. The earlier 0/1/2/3 dB bundle remains a separate texture-only evaluation.

The official-checkpoint disk runner matched a saved real 14-second reference exactly in float32; interrupted resume and corruption rejection passed. Latest resumed inference peak RSS was 823.6 MiB, separate postprocess 474.1 MiB; 3 CPU threads / 35% duty / GPU off after resume, with RSS/swap backoff. First 13 windows used MPS, and timings exclude earlier attempts/pauses. No controlled listening verdict or full-song cross-device bit identity is claimed. The two early-validation fixes, earlier adverse cases and existing fork CI evidence remain in the description; upstream workflow approval is still required. Keeping Draft.

Published asset verified against GitHub size and SHA-256: 285822013 bytes; 0dddee5949adb5ca88c5254367109d7fe704b82020575b6d4877193952aea030.

[hemanpapa-coder]

Creator listening feedback and follow-up plan (2026-10-19)

After comparing the published full-song versions, the song creator reports a substantial subjective improvement over upstream Apollo in noise suppression and reduction of rough texture. However, the current full-application enhancement also sounds somewhat muffled: high-frequency openness is reduced, and guitar and piano sounds are less distinct. These are the creator's informal listening observations on this one Suno song, not a blinded listening study or a general quality claim. Exact affected timestamps and stage-specific causes have not yet been established.

The current comparison files, measurements and published ZIP will be retained unchanged as the evaluation baseline, including these audible limitations. This feedback concerns the complete application chain; it does not establish that the narrow default-OFF texture option alone causes the reported loss of clarity.

The next candidate will aim to preserve high-frequency openness and guitar/piano definition and attacks while retaining the current noise reduction. Stage-by-stage comparisons are planned to identify where wanted musical detail is attenuated; the cause and an effective remedy remain unverified.

When a revised version is available, it will be published as a separately identified candidate rather than replacing the current files. The follow-up comparison will retain the same source and align original input / upstream Apollo / current full-application enhancement / revised candidate at consistent loudness and common peak headroom. Affected timestamps, configuration and source changes, improvements and remaining or adverse effects will be documented in a subsequent PR update. No revised audio or successful fix is claimed yet.

Keeping this PR as Draft for further listening and maintainer evaluation. Existing full-song comparison and provenance.

[JusperLee]

Thanks for the additional examples and for documenting the limitations and listening feedback.

I’d like to keep PR #44 focused on the optional texture-softening stage. The full enhancement chain introduces several additional inference strategies and DSP stages, each requiring separate evaluation and maintenance.

Please keep the full enhancement chain in your fork or propose it in a separate experimental PR. For this PR, please retain only the texture processor, its CLI integration, relevant tests, and concise documentation. Larger comparison bundles can remain in Releases and be linked from the documentation.

Once the scope is reduced, we can evaluate the texture-only comparisons and decide whether that feature provides enough benefit to merge. Further work on the full enhancement chain should happen separately.

[hemanpapa-coder]

Thank you for clarifying the scope. PR #44 has now been narrowed to six files covering the optional texture processor, CLI integration, focused tests, concise documentation, and the required SciPy test dependency. The full enhancement chain and larger evaluation materials remain available in the fork’s history and existing Releases.
The updated commit is 14b9e53. All 33 local CPU tests and the fork CI tests passed: https://github.com/hemanpapa-coder/Apollo/actions/runs/39392480837
The verified eight-excerpt texture-only comparisons are available here: https://github.com/hemanpapa-coder/Apollo/releases/tag/texture-evaluation-20261016
The limitations remain documented, including possible loss of wanted detail, O(duration) post-processing memory, and no controlled listening result or lossless clean-master reference. The upstream workflow is awaiting maintainer approval. The PR remains Draft for your evaluation.

[JusperLee]

Thanks for narrowing the PR to six files. This addresses my earlier scope concern. I reviewed commit 14b9e53 and reproduced all 33 unit tests locally. I would still keep this as Draft and defer merging until the benefit is better established.

I also ran waveform and spectral checks on all eight 15-second excerpts in the texture-only comparison bundle. I verified the hashes of the 24 WAVs used for this analysis, regenerated the 1/2/3 dB variants from the supplied 19-second Apollo contexts, and confirmed that all eight regenerated 3 dB outputs match the published samples exactly. These checks did not include a new checkpoint inference run or a blinded listening test.

At the 3 dB setting:

• Total energy in the 1.2–14 kHz band decreased by only about 0.004–0.047 dB across the excerpts, although individual internal STFT gains reached roughly 2.3–2.7 dB of attenuation. The overall modification is small and localized.
• The difference signal contains structured, harmonic-like patterns, including around 13–14 seconds in the vocal excerpt and 1–2 seconds in the piano control. This does not establish audible damage, but we cannot assume that everything removed is an unwanted artifact.
• Against the supplied source proxies, gain-aligned waveform SNR changed by approximately −0.030 to +0.011 dB. Log-spectrum RMSE increased slightly in all eight excerpts. These changes are very small, and the references come from lossy recordings, so these metrics alone cannot establish perceptual improvement or deterioration.

The current full-output STFT also retains its O(duration) memory cost. Your reported 180-second repeated-prediction probe reached about 3 GiB process RSS, excluding the model; I have not independently repeated that memory measurement.

The remaining concern is whether the perceptual benefit justifies the resource cost and ongoing maintenance. A small, level-matched blinded comparison using the existing texture-only clips, with specific timestamps, listener preferences, and any loss of detail or transient clarity, would be the most useful next step. We can revisit merging once there is clearer evidence of a worthwhile benefit. Please keep the full enhancement chain separate.