The audio de-synchronizes after a little while and I don't understand why. But I also don't care that much, since it's meant to be played silently. However if you find a fix, let me know.
THE CYBERIZER!
THE CYBERIZER analyzes videos to find the scene breaks and then shuffles and re-assembles them with a burst of static in between. Twenty hours of music videos go in, and three hours later, six hours of mind massage squirts out. You can see this project making its live premiere at CYBERDELIA on Feb 28! I tried to upload six hours of it to Youtube last week, and that's what got me the record-breaking take-down notice, but it looks a little bit like this:
Tags: art, computers, copyright, dnalounge, firstperson, glitch, mad science, mpegs, music, tv, xscreensaver
7 Responses:
For what it's worth, I have some audiobook-related tooling on GH that also loses time sync over long durations. I've hacked at it for years and never gotten it perfect.
As near as I can tell, ffmpeg (and similar tools, including perl audio modules) don't actually calculate real durations, they just give a "close enough" estimate based on the frame count or something. It works for joining a few songs, but the jitter adds up over hours, especially for lots of tracks.
A number of tools have an equivalent to "ignore xing header", which sometimes helps a little if the tool is completely braindead about VBR because it was written in 1994 or something.
Also, it didn't look like you were doing it in the tool, but should you use sox to crossfade or beat match, it takes the duration of the overlap as a recommendation, not a hard target. At which point there's no way to know the resulting duration with any precision without writing out the file and reading it back in after each join.
My first thought (well, second thought; the first was "damn, that's cool") was that some of the clips are too short and everything blurs into the static, so I appreciate this:
# --min-clip-length H:MM:SS Don't allow any input scene to be shorter
# than this. Default 4 seconds.
It's good to see that somebody still believes in user preferences, not "You'll take what we give you and like it, peasant."
This is relevant to my interests, but I'm getting a warning and a "short file" error when I try to run the code. It seems to ingest the videos fine (from the command line), but then exits...
nesf$ perl cyberizer.pl --max-length 0:10:00 --out out.mp4 *.mp4
cyberizer.pl: creating video of length 0:10:00...
cyberizer.pl: scanning for scene breaks in 11 input files...
cyberizer.pl: selecting scenes... 0:00:00
cyberizer.pl: selected 95 of 290 scenes; extracting...
Use of uninitialized value in numeric lt (<) at cyberizer.pl line 620 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
... cut ...
cyberizer.pl: short file: /tmp/cyberizer.37a84119-00000.00001.ts from static.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'static.mp4':
... cut ...
When in doubt, upgrade ffmpeg. Run it with -vvvv to see the full ffmpeg log. If it breaks you can keep both pieces.
OK, here's the comment where I confess to "pilot error." Looking at the logs, it was my lack of libfdk_acc that was causing the abort. (libfdk_aac is no longer available in prebuilt ffmpeg binaries.) Once I commented out that line in the ffmpeg options and went back to aac, it completed. It's all good.
Any chance of getting the full video through some other means?
Can anyone explain to me why my output files have weirdo frame rates of 26.13 fps or 26.06 fps even though I've specified "-r 30" in my encoder options?
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 3946 kb/s, 26.13 fps, 30 tbr, 90k tbn, 60 tbc (default)
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 3902 kb/s, 26.07 fps, 30 tbr, 90k tbn, 60 tbc (default)
-c:v libx264 -profile:v high -pix_fmt yuv420p -acodec libfdk_aac -b:a 192k -r 30 -movflags faststart -max_muxing_queue_size 10240