Exports keep their colour and their sound
Two faults that only showed after a file had left the editor: a brand red that came out a slightly different red, and a loop whose sound stopped before its picture did. Both are fixed, and a few quieter ones with them.
The colour you picked is the colour in the file
A video file has to say which colour standard it is in, and a player that is not told guesses. Ours were not told. In Chrome a brand red of #ff0033 came out as 255, 27, 50 — up to 39 steps out of 255 off — and QuickTime on macOS was off by as much as 40.
Cloud exports in H.264 and ProRes are now converted to BT.709, the standard for HD video, and tagged as such inside the file. Measured the same way, colours land within 3 steps of what you chose. WebM is left as it was.
Sound for as long as the picture
An export set to loop two, three or five times used to come out with its sound shorter than its picture — every one of twelve looped test exports, one of them 13.1 seconds of sound on an 18-second video. The mix is built for the whole length now, at 48 kHz, and across more than a hundred runs none came out short.
A machine whose FFmpeg lacks the part the new mix uses still exports sound, the way it did before, instead of failing.
The same words wrap the same way
Exporting here, in this tab, now wraps a word too long for its box the way the editor does. A long title had been four lines in the editor and five in the file; they agree now, and every earlier test frame is byte-for-byte identical to what it was.
Quicker to start, safer to reload
Starting an export reads only the records it is about, so the time to register one fell by about half, from around 2.4 seconds to around 1.3. The editor opens without building parts it will not use.
And a reload opens on your newest work rather than on the copy a save was carrying at that moment. In the test built for it, a renamed marker was lost in 25 of 40 reloads before the fix and kept in all 40 after.