Hi! First of all, thanks for Apollo, really appreciate the work being open.
While running long tracks with chunking I noticed a faint dropout recurring every few seconds, and it turned out to line up exactly with the chunk boundaries.
What I measured. Using only the repository's own 6 s fixture (asserts/input_wav.wav), tiled to 20 s, with --chunk-seconds=6 --overlap-seconds=1: the SNR of the chunked output against a single unchunked pass collapses at every seam.
The cause seems to be that the model's output is wrong near the edges of its input. Restoring the same audio twice with different chunk positions and subtracting the two outputs: they match bit for bit except within around 0.5 s of an input edge, where the difference reaches a high level at the trailing edge. From my limited testing, the extent stays about 0.5 s whether the chunk is 4, 6, or 10 s long. The overlap crossfade then blends exactly those regions into every seam.
As you notice there is also another faint difference at about 6s, 12s, and 18s. This I did not investigate yet.
I worked on a fix already #42. It adds a --chunk-pad-seconds option. Each chunk is inferred with that much surrounding audio per side, discarded from the output, so the seams are built only from audio predicted with context on both sides. The default of 0 reproduces the current output bit-exactly and the existing test suite passes unaltered; 1.0 adds enough audio context to fix the issue, again, from my limited testing. Two tests cover the new behavior.
Happy to adjust anything about the approach or naming, and thanks again!
@Djshinshin tagging you since I see you're the one who worked on chunking, this might benefit from a review from you too ;)
Hi! First of all, thanks for Apollo, really appreciate the work being open.
While running long tracks with chunking I noticed a faint dropout recurring every few seconds, and it turned out to line up exactly with the chunk boundaries.
What I measured. Using only the repository's own 6 s fixture (
asserts/input_wav.wav), tiled to 20 s, with--chunk-seconds=6 --overlap-seconds=1: the SNR of the chunked output against a single unchunked pass collapses at every seam.The cause seems to be that the model's output is wrong near the edges of its input. Restoring the same audio twice with different chunk positions and subtracting the two outputs: they match bit for bit except within around 0.5 s of an input edge, where the difference reaches a high level at the trailing edge. From my limited testing, the extent stays about 0.5 s whether the chunk is 4, 6, or 10 s long. The overlap crossfade then blends exactly those regions into every seam.
As you notice there is also another faint difference at about 6s, 12s, and 18s. This I did not investigate yet.
I worked on a fix already #42. It adds a
--chunk-pad-secondsoption. Each chunk is inferred with that much surrounding audio per side, discarded from the output, so the seams are built only from audio predicted with context on both sides. The default of 0 reproduces the current output bit-exactly and the existing test suite passes unaltered; 1.0 adds enough audio context to fix the issue, again, from my limited testing. Two tests cover the new behavior.Happy to adjust anything about the approach or naming, and thanks again!
@Djshinshin tagging you since I see you're the one who worked on chunking, this might benefit from a review from you too ;)