We verify audio, sync, and the MP4

Every release on Autoretto goes through a quality gate before it reaches a YouTube channel. This is not a checklist someone clicks through. It's a set of automated checks that open the actual files and inspect them. We do this because AI-generated media can look perfect in a dashboard and fail on playback. A video might have a mismatched audio track. A song might decode into silence. We want to catch those problems before they go public.

The first check is real audio decoding. When Suno produces a track, we don't trust the metadata that says 'MP3, 44.1 kHz, 320 kbps.' We run the file through a decoder. We confirm it decodes end to end. We measure the duration. We look at the waveform for clipping and for long stretches of silence. We also check that the audio stream actually has data. It's easy for a generator to write a header with the right numbers and then produce nothing usable. We catch that with the decode test.

We also keep an ear out for slop. Slop is the vague mush you get when an AI fills space with sounds that go nowhere. We can't hear it, but our checks can. We look for repetitive transients and a lack of dynamics. We measure the difference between peak and RMS levels. If a track stays in a narrow band and never changes, we flag it and re-roll the generation. Sometimes the fix is a different prompt. Sometimes it's just letting Suno try again.

The second check is audio-to-video sync. Autoretto renders a beat-synced video, which means the scenes change with the beat of the song. The sync has to be frame-accurate. A drift of even a few frames is noticeable. So we don't trust that the render engine did its job. We test the final MP4. We extract the audio track and detect beats. We extract the video and detect scene changes. Then we compare the timestamps. If the beat and the cut don't line up within a threshold, we re-render.

The sync check is strict. If a high-energy section has visual cuts on the wrong frames, the video feels off. We use a tolerance of one frame at 30 fps. If the cut is two frames late, we throw it back. Some releases take three or four renders before they pass. That's fine. We'd rather burn compute than publish a video that looks like a student's slideshow.

The third check is the MP4 artifact itself. We refuse to claim a publish without a verified MP4. That means we don't just call the YouTube API and assume the upload worked. We first verify the local file. We check that it's a valid MP4 container. We make sure it has both a video stream and an audio stream. We confirm the codecs are YouTube-compatible. We check the file size is within a sane range for the duration. Only then do we hand it to the uploader.

And after the upload, we verify the YouTube side. The API returns a video ID, but we check that the video is actually live. We look up the status. We confirm the duration matches. If any step fails, we don't mark the release as published. The schedule does not advance. The release stays in the queue with an error attached. We get a notification, and a human can decide what to do next.

These checks are part of the loop that feeds the optimizer. A release that passes is a release that really exists. That gives the performance data a clean foundation. Without them, we'd be learning from failures as if they were successes. The quality gate is not about being fussy. It's about making sure every published video is a real artifact that a viewer can play, watch, and hear.