no sound for last 1 to 30 seconds of video

[D M]

Downloading music videos from youtube, some songs will have missing audio for last few seconds, from approx 1 to 30 seconds. This is random, maybe 10-15% of downloads are affected. It may take a few tries to get a proper download.

I am using Video DownloadHelper 7.6.6 on Firefox 108.0.1 on Linux Mint.

Happens with or without companion app.

[Wild Willy]

I have encountered videos that were faulty.  Parts of their audio really were missing.  Whoever uploaded the content must have screwed it up.  It's possible.  It happens.  Is that your case?  Post a few URLs & let others try to replicate your results.  I must say that YouTube is notoriously inconsistent so nothing would surprise me.

[D M]

It is a random occurrence. Repeating the download will eventually result in a proper recording.

Here is a test I did with a few videos,

YT Video ID | length | seconds of audio clipped at end of video (multiple downloads)
905czCk919k   2:08     12  0  0 12  0  0 10 11  0 11
XwfG9FdhAc0   2:10      0  0 14 16  0 15  0  8  0  0  0
I5XkzBlTV5g   1:05      9  0  0  0  0  0  0  0  0  0  0
SRczGJ-4M5g   3:46      *  0  0  *  *  *  *  *  *  *
NE2AvbROl5k   3:34      0 11  0  0 11  0  0  0  0  0
uP_iLS38Tdo   2:35      0  0 15  *  0  0  5  *  0  *  0  0  0 15
* failed aggregating

+/- 10 files in the queu, only one download at a time.

youtube-dl appears to work fine, for the samples I tried up to now.

Is there a debugging mode to track what is happening? in order to compare a bad download with a good one.

[jcv...@gmail.com]

Is it something you can reproduce ?

I tried the first in your list https://www.youtube.com/watch?v=905czCk919k and had no sound problem.

jerome

[D M]

@jov The only way you may be able to reproduce the problem is by downloading the video multiple times and checking each download. As the test table I show, sometimes it works, sometimes audio is clipped. It is random.

[jcv...@gmail.com]

Sorry, I tried 5 times, no problem with the sound for me.

jerome

[Harry Skelton]

Same problem for my on any platform (Linux Mint, Linux Ubuntu,etc...). A possible catch is the video format. It seems to rear it's ugly head with videos greater than HD.  I try to get 4k versions and they all have the missing audio. There should be a test for audio length vs video length, or at least a tick box we can select to force this. It might also be a problem with YouTube and it trying to insure DRM or video rights at any level. Anyway, this needs to be seriously checked by the developers.

I look forward to a solution...

[Wild Willy]

This is unlikely to be solved any time soon.  It's going to take some, probably a few, sample videos that display the problem reliably.  That means EVERY time, not intermittently.  Even the original poster sees this only intermittently.  Jérôme tried it & couldn't replicate the problem.  I've never seen it, either.  You have to put yourself in the developer's (Michel's) shoes.  If he doesn't have a use case to test on, he can't locate any bug, which I would have to characterize as an alleged bug, in VDH.  This is just how programming works.  Until one of us can stumble upon that magic use case that always fails, there's nothing any of us can do except suck it up.

[K Wood]

You guys aren't getting it.  The problem is that videos DO NOT "display the problem reliably."  There is no way to predict when this will happen, and sometimes downloading the same video again will work fine, or sometimes the audio drops even sooner.

This means that there is no way to replicate the problem, you have to be "lucky" to experience it.

It is not a problem with the file being downloaded -- the video plays just fine.  It's the downloaded file that is bad, even though VDH acts normally during the download.  That makes it a bug in the code that VDH uses to handle audio, not having anything to do with the video before it VDH starts working on it.

It happens here often enough that I have to verify that the audio runs to the end after each download.  Of the half dozen I did this morning 3 have the problem, and that's why I came here in the first place.  I'm looking for an alternative to VDH that will work without problems, I don't have the time to screw around with 2 or 3 tries to download a file.

Sometimes the video is also screwed up, and the playback freezes with a bad frame displayed.

[Wild Willy]

I think there's lots of not getting it all around.  In order for a programmer to solve a bug, he has to have a test case that forces processing through the code that contains (allegedly contains) the bug.  By your own admission, this is intermittent.  Jérôme, who works for VDH, tested one of your test cases & could not replicate your results.  I have never had a YouTube video download with truncated audio as you describe.  The conclusion I come to here is that you have something weird happening on your system.  I have weird things happen on my system.  VDH likes to give me 1912x1088 videos that are actually 1920x1080.  I think your system has a weird thing going on.

If you want an alternative, check out this discussion:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/sNfTCMYfiTU

There's a collection of evasive maneuvers described in there.  Maybe one of them will work for you in some of your cases.  I can say that VDH gives the URL of the video track & the URL of the audio track in its Hit Details.  I have successfully downloaded those tracks using ffmpeg.  That's as much of a hint as I'm going to give.  I've written instructions out in full elsewhere in this forum so I'm not going to repeat all that here.  Spend the time, put in the effort to read that other thread.  Maybe there's something in there that will help.  What you have presented here does not seem amenable to investigation of a bug.  Most people aren't encountering what you are.  At least one person is, but most of us aren't.  So my guess is you're going to have to rely on the alternative solutions.

[Amy McLaughlin]

Apologies for the thread necromancy, but I think I know some videos that will reproduce the issue reliably. I've contacted the person affected, and she should be able to send me the Youtube URLs within a day or two. I'll post them in this thread when I have them.

Cheers!

Amy.

[Matt Carter]

I have dealt with this problem for years.  I have always run Firefox on several Macs and all have had the problem at some point, sometimes lasting months or years, sometimes going away for months or years.  Any software update can cause it to come or go.  The only two things that can increase the occurrence of the problem is the number of simultaneous downloads and the internet connection.  If i run more than 4 downloads at once on the home DSL, I tend to get more "End Chop."  If I am on the fiber optic connection at work, I can run up to 10 downloads at once.  The problem can also occur more often if I build a big cue of downloads.  It "feels" like the problem is with some operation overloading and losing synchronization.  To make the problem worse, recently the End Chop has also been effecting the video, which also freezes the video time indicator in VLC.  I have not tried an alternative player for years.  The last time I did  it was clear the problem was in the video data, not the player.

Yesterday, I purchased a new MacBook.  I don't know what it will do to the End Chop problem but I hope it helps. 

[Matt Carter]

I just sent a reply to Willy about the occurrences when i have the End Chop problem.  Please read it to see if you se any similarities to your experience.

[Wild Willy]

I don't work for VDH. I have posted that in this forum on numerous occasions. I DO NOT
WORK FOR VDH. I'm just another user, like almost everybody else who posts here. Only
Michel (who posts here as mig) & Jérôme (who has posted above in this thread) work for
VDH. Michel is the developer of VDH. As far as I can tell, he is the ONLY engineer
working on the product. Jérôme helps out by monitoring this forum so Michel doesn't have
to. So people should NOT E-mail me anything. If you have something to say that
progresses the discussion, you should post it here, as a regular post, so the maximum
number of people can read it & chime in here. But it doesn't matter because I have not
received any E-mail from you, Matt. That's good. Don't retry it. Just post whatever
you have to say here. Use Reply all, NOT Reply to author.

That's out of the way. Now we can deal with the issue at hand. I first reported a
problem about multiple concurrent VDH downloads in this thread:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/lCy0hw8t-uE

I had a hard time finding that one, it's so old. But the topic has come up a number of
times since. I just searched for those discussion & found a few that are on the topic.
Problem is they are also to a large extent off the topic. That other thread I've just
cited is mostly still relevant but I have learned a few things in the 4 and a half years
since. (No kidding? It took me only 4 and a half years. I'm so smart.) The short
story about the multiple concurrent downloads is this. An MP4 includes something called
a moov atom. I am no expert on the thing & what I know is actually subject to challenge
from someone who does know. It is my understanding that the moov atom is metadata about
the MP4. It includes information like resolution, frame rate, duration, & I don't know
what else. It is information required by playback applications (like VLC). Michel has
explained in here somewhere (good luck finding it) that he keeps the moov atom in program
storage while VDH is downloading something. He does not write it periodically to a file,
not the target file of the download, not some temporary side file. This means that it is
subject to management by the operating system's paging mechanism. When the operating
system is Linux in one of its plethora of mutations, I gather the operating system does a
good job of managing its paging algorithm. Michel develops VDH on Linux so he thinks
this architecture is a good idea. But out here in the real world, there's a lot of folks
relying on Microsoft. For example, I run Windows 7. The paging algorithm in Windows is,
shall we say, less robust. As I describe in that thread I've just cited, it is easy for
me to bring my system to its knees due to thrashing on the pagefile. It's so easy that I
have managed to avoid doing it in a very long time. I will either single-thread my
downloads in VDH or I will use ffmpeg instead. Ffmpeg isn't subject to the thrashing
problem because it manages the whole process of downloading in a different way. That
sounds like I know what that different way is. I don't. I just know that I can run
multiple concurrent large downloads with ffmpeg & the thrashing problem doesn't occur.
The only conlusion is that ffmpeg does things completely different from VDH. In that old
thread I mention my slow Internet connection. Since that time, I have subscribed to a
different ISP & my bandwidth is now 100 times what it was. But that does not affect the
thrashing problem in VDH. That is still present.

In any case, if you are trying to push multiple large downloads through VDH at the same
time, you are probably hitting this thrashing problem. When the thrashing occurs, it's
likely that only one of your downloads completes successfully, and that only after an
unreasonably long delay. The rest of your downloads probably time out during that long
delay. When that happens, VDH usually just prematurely terminates those downloads
without writing the moov atom. Usually, not always, but usually. When a file doesn't
have a moov atom, it is not simply impossible to play it. The tools I found that claimed
to be able to repair videos all told me that they couldn't repair such interrupted
downloads because there were no moov atoms in the files. Catch-22. I speculate that
some form of this problem is occurring when you have a truncated audio track..

So don't try to download multiple concurrent videos with VDH. Single-thread them. It
doesn't matter what your bandwidth is. Single-thread your VDH downloads. Go into your
VDH settings & look for these 2:

Max concurrent downloads
Max concurrent stream downloads

Set them both to 1. That's how you single-thread downloads in VDH.

It is my understanding that the MKV format does not rely on a moov atom. I have no idea
about WEBM. Still, to be safe, I recommend single-threading VDH until we hear from
Michel that he has changed the architecture of VDH. I would not hold my breath waiting
for that. I reported that thrashing problem 4 and a half years ago. The VDH
architecture has not changed.

Despite all of that, I am still waiting for somebody here to post some URLs of videos
that you downloaded with truncated audio tracks. Amy McLaughlin has teased us with a
promise to do that. I hope she follows through. By URLs I mean URLs to the web pages
where one of us can download the same videos. I don't need to see one of your videos
with a truncated audio track. That is no help. I need to do the same download you did &
see if I get the same result. Long-winded treatises (I can write those with the best of
you, present post being proof) are not really advancing us towards a solution. Post some
URLs. Let me (and other people, that's why you should post & not send private E-mails)

[Wild Willy]

Google has done it again. I don't know why it does this. It has decided that the last
line of my previous post is a signature line. It's not. So you need to click the 3 dots
below my post in order to see the last line of it.