Tuesday, April 22, 2025

Prometheus v3.62 Fixes

The last couple of days have been busy with essential anniversary duties. It is exactly 9 years since I met Deborah on ArtsLab. Aside from my primary mind being attending to her, my secondary mind was working on an annoyingly simple and annoyingly complex Prometheus bug which has taken two days to fix.

It's not a bug as such, but a slight error regarding precalculation. If I have a song that's, say, 4 seconds long and 4 beats. I can render the whole thing, a 4 second wave with beats 1-2-3-4. I can render just the first half, beats 1-2, and render just the second half, beats 3-4. Joining that first half and second half should produce an exact a copy of the full song; but this didn't happen. It was annoyingly a few samples out, 60 to 200 samples or so, a few milliseconds.

This has been the case since I added 'precalculation' to Prometheus. When playing from the middle of a song, the program runs itself from the start so it can know the correct timing (and even calculate the audio, if required) at that point. A few samples out here and there don't make a difference here. Precalculation is primarily used when previewing a song, not as a final result, so it didn't need to be 100% accurate.

But if I'm to use Prometheus to master an album, it does.

I knew this was due to the timing calculations during the precalculation loop but it took hours of musing to work out. In the bath last night I had a eureka moment; that rather than run up to the second half, I had to run up to one sub-tick just before the start time, so that the very next loop would start with the variables set as though the full song were rendering at that point.

This was fixed today, it works! And now the CD timecode quantisation too. With this, rendering any file will skip to the next 'global' 588-sample boundary and extend to the next frame boundary at the end; so I can, if needed, use Prometheus for CD mastering with exact timing.