News:

--

Main Menu

Audio Bug at Video Start

Started by Cormy1, April 24, 2018, 04:00:17 PM

Previous topic - Next topic

Cormy1

Took a JPG, copy pasted for 5 minutes, slapped in MP3 audio track, exported as MKV.
There's a strange chirp at the start of the vid and since there's no audio fade option, I don't think I can remove it...?
Also unsure of why the video is just as large with a framerate filter set to 1FPS as it is for the default 25FPS...
Also how do I save a project, instead of exporting a vid?
Reimporting the video yields a video bug, audio plays fine.

eumagga0x2a

Quote from: Cormy1 on April 24, 2018, 04:00:17 PM
Took a JPG, copy pasted for 5 minutes,

Use a recent Avidemux nightly, it includes a "Still picture" plugin which generates a 25 fps movie out of an image hassle-free.

Quoteslapped in MP3 audio track, exported as MKV. There's a strange chirp at the start of the vid and since there's no audio fade option, I don't think I can remove it...?

I would always use an uncompressed WAV as source of an external audio track and reencode it in Avidemux.


QuoteAlso unsure of why the video is just as large with a framerate filter set to 1FPS as it is for the default 25FPS...

Don't alter framerate, use the "stillimage" tune for x264.

QuoteAlso how do I save a project, instead of exporting a vid?

File --> Project Script -->Save as project

QuoteReimporting the video yields a video bug

Which one?

Cormy1

Is the Still picture plugin different from the stillimage tune for x264 you mentioned? Configuring the x264 codec doesn't seem to have a stillimage tune in 2.7 at least.
If I had a WAV source, I would use it. But I will not decode the mp3 to wav and reencode it lol
Aaand I can't attach a 2MB video... Yeesh.
https://www.file-upload.net/en/download-13103531/2018-04-2820-37-11.mkv.html

eumagga0x2a

Quote from: Cormy1 on April 29, 2018, 10:36:23 AM
Is the Still picture plugin different from the stillimage tune for x264 you mentioned?

What a strange question! The "Still picture" video filter duplicates a single frame over and over again (up to 9999 times for now) until a given duration (max. 400 seconds ~6,5 minutes) is reached. The output of video filters is passed to a video encoder.

The stillimage tune represents pre-defined settings for the x264 video encoder optimized for video with very little motion in it, like the one generated with the help of the "Still picture" video filter.

QuoteConfiguring the x264 codec doesn't seem to have a stillimage tune in 2.7 at least.

You must uncheck the "Use advanced configuration" checkbox first. This tune has been there for ages (for at least 4 years).

QuoteIf I had a WAV source, I would use it. But I will not decode the mp3 to wav and reencode it lol

You could try to enable audio shift, set a negative value high enough to make the noisy frames get dropped and save in copy mode.

QuoteAaand I can't attach a 2MB video... Yeesh.
https://www.file-upload.net/en/download-13103531/2018-04-2820-37-11.mkv.html

Currently, this site serves Mac malware instead of video. WeTransfer has been reliable so far.

Cormy1

I assume the Still Picture filter is superior to the framerate change/resample that is stock with avidemux?
I believe I had kept both video and audio to copy previously, so you do recommend re-encoding it with x264?
Not sure how images are handled into a container with copy.
I don't believe audio shift will help, since the glitch is not present in the source audio, but is introduced by avidemux in the exported file.
I suppose I could shift it on the exported file, but as I mentioned, the video also seemed corrupt so I don't think it would be good to re-export that.

https://we.tl/qAajGqA2fl

eumagga0x2a

Quote from: Cormy1 on May 03, 2018, 06:39:30 PM
I assume the Still Picture filter is superior to the framerate change/resample that is stock with avidemux?

They serve different purposes.

QuoteI believe I had kept both video and audio to copy previously,

If you use filters, you have to reencode, beliefs notwithstanding.

Quoteso you do recommend re-encoding it with x264?

Sure.

QuoteNot sure how images are handled into a container with copy.

I don't quite follow you. A container combines one or more video streams with one or more audio streams (and sometimes other data like subtitles). You need a valid video stream. How you obtain it, is another story.

QuoteI don't believe audio shift will help, since the glitch is not present in the source audio, but is introduced by avidemux in the exported file.
I suppose I could shift it on the exported file, but as I mentioned, the video also seemed corrupt so I don't think it would be good to re-export that.

It is not a question of faith. Please generate the video stream as recommended with the "Still picture" video filter + x264 with the stillimage tune. If you need more than 6 minutes duration, add the video filter twice. Add the external audio track with audio in copy mode. Save the result as MKV. If the audio glitch is present, try the suggested workaround. Either is works or it doesn't.

Quotehttps://we.tl/qAajGqA2fl

The screen capture is pointless while the external audio file as a sample might have been helpful. Apart from that: Don't use the release, it is as old as the hills.

Cormy1

So if I just copy-paste images, and export the file in a container, with audio and video set to copy, how is the video stream generated?
Why should encoding the video using Still Picture and stillimage yield different behaviours in the audio result when audio is still set to copy? Funny that you say it isn't a question of faith without giving reasoning for your troubleshooting methods... This is a bug, whether the solution works or not isn't really an issue, the bug exists and should not exist.
The screen capture displays both the video import glitch, and audio glitch I had mentioned. It shows that the audio glitch is only present in the export, and that the video bug only occurs on import of the finalized video.
The external audio sample would be useless, since there is nothing wrong with the audio that is imported into avidemux, just the export is bugged, which is included in the screencap. Additionally, the video bug is in the screencap so it was necessary to demonstrate both within a single simple video.
Interestingly, trying to extract the audio track from the bugged export using Audacity yields an enormous amount of silent sections which aren't present during video playback.

When you say not to use the "release", do you mean the 2.7 branch? I thought the releases linked on Avidemux were supposed to be stable branches, are you saying the nightly builds have fewer bugs than the stable 2.6.7 or 2.7 release builds?
I could try re-doing it on one of those to see if the bug is fixed before trying workarounds, is there one of these you recommend?
http://avidemux.org/nightly/win64/

eumagga0x2a

Quote from: Cormy1 on May 04, 2018, 02:11:59 PM
So if I just copy-paste images, and export the file in a container, with audio and video set to copy, how is the video stream generated?

If the source image was a JPEG, you get a MJPEG movie (all frames are I-frames). I tried it with a 1280x720 JPEG image, 140 kiB in size, pasted over and over again to reach 3,5 seconds total duration, and added a MP3 sound track. The resulting MKV was 13 MiB in size, there was no audible noise at the audio start.

QuoteWhy should encoding the video using Still Picture and stillimage yield different behaviours in the audio result when audio is still set to copy?

In both cases I get no noise at audio start, but the size of the output when using the "Still picture" filter and x264 with the stillimage tune is just 188 KiB for exactly the same duration.

QuoteWhen you say not to use the "release", do you mean the 2.7 branch?

No, I mean the 2.7.0 release. There is no 2.7 branch, the release was a snapshot of the git master from August 14, 2017.

QuoteI thought the releases linked on Avidemux were supposed to be stable branches, are you saying the nightly builds have fewer bugs than the stable 2.6.7 or 2.7 release builds?

They are currently much more stable, with a lot of issues present in releases resolved.

QuoteI could try re-doing it on one of those to see if the bug is fixed before trying workarounds, is there one of these you recommend?
http://avidemux.org/nightly/win64/

Take the latest (r180504).

Cormy1

Audio Glitch still present with "vanilla" copy/copy settings on 5:01 minutes of video, also present with Stillpicture and stillimage settings.
Shifting the audio forward shifted the glitch forward, shifting it back removed the glitch from the resulting video.
Tried it with a different mp3, glitch not present but again, the glitch is only present in the export, not in the project playback nor in any of my media players and it doesn't show up in audacity, except when the exported video is brought into Audacity. The glitch audio lasts less than a frame, about 20ms.
Tested with the build you suggested.

eumagga0x2a

Quote from: Cormy1 on May 05, 2018, 05:28:00 PM
Shifting the audio forward shifted the glitch forward, shifting it back removed the glitch from the resulting video.

Exactly as advertised.

QuoteTried it with a different mp3, glitch not present

This means, the glitch is likely specific to a particular audio file.

Quotebut again, the glitch is only present in the export, not in the project playback nor in any of my media players and it doesn't show up in audacity, except when the exported video is brought into Audacity.

What makes you sure this is not an issue with Audacity then?

All above sounds for me very much like a non-issue, but in doubt please provide the problematic source mp3 file as a sample.

Cormy1

#10
Hmm?
I think you misunderstood.
The audio glitch is present in the video, regardless of what I use to view the video. Extracting the audio from the video using audacity allows me to view the glitched audio that has been INTRODUCED during the export/save from avidemux into the resulting video.
The mp3 sourcefile does not have the audio glitch regardless of where I view it, including in audacity.
mp3: [No longer needed]

eumagga0x2a

#11
Thank you, I can reproduce with this sample. The noise results from a damaged first frame, maybe we get the offset wrong when dealing with album cover prepended to the file. The workaround is to delete this part of the file in hex editor, so that it starts directly with the actual MP3 header. I've uploaded the shortened mp3 to

[ No longer needed]

No wonder I couldn't reproduce with my own samples – none has cover art prepended to audio.

The reason there is no noise in Avidemux when playing the saved video with audio track from the unmodified mp3 file is that Avidemux uses libmad for MP3 decoding and libmad handles bad CRC error very gracefully. Other players use mostly ffmpeg for decoding, and ffmpeg doesn't conceal the damage here.

Cormy1

Again I don't understand.
The glitch is only present in the exported video, which means it is introduced by an encoding error, not decoding, and also due to something within avidemux itself that isn't handling the file properly. If it were a decoding issue with ffmpeg, I feel that it would show up in far more places while trying to play the mp3 itself. Strangely, since I've only ever been using copy, I don't see why it would/should try to re-encode the audio at all, unless audio with covert art can't be wrapped without being re-encoded.

eumagga0x2a

#13
Strictly speaking, it is not a damaged first audio frame but garbage data (parts of the id3v2 tag) before the actual mp3 data begins. If players try to interpret this garbage as audio, you hear the noise. The bug is somewhere in Avidemux code parsing external mp3 files and creating audio tracks from them.

Don't reencode audio, just strip id3v2 tags section from the mp3 file before using it in Avidemux.

eumagga0x2a