View Full Version : "MP4box is not a valid win32 application"
Katie Boundary
22nd June 2021, 03:59
I normally prefer AVI because muh compatibility, but I have a friend who's hiring me to do some video stuff and he wants everything in MP4, so today I downloaded and installed MP4box for the first time and... this was the error message I got.
Let me guess. They dropped XP support?
EDIT: I'm in my win7 partition now and... umm... it's been doing this for a while. Is this normal? Should I be worried?
(Yes, I have an N:\sync directory)
https://i.imgur.com/lZSn8eK.jpg
Katie Boundary
22nd June 2021, 06:00
It's been doing this for about 2 hours so I'm going to assume it's not working as intended.
filler56789
23rd June 2021, 03:10
Two suggestions:
1) give a try to some old version(s) of MP4Box;
mine, for example, says: "MP4Box - GPAC version 0.8.0-rev1-gc1990d5c-master".
2) make sure that the MP3 stream was generated correctly.
I have already found various ancient, lousily-encoded MP3 files which for example were played fine with MPlayer but caused problems to LAV Filters...
SeeMoreDigital
23rd June 2021, 09:09
I normally prefer AVI because muh compatibility....
That's bonkers... Stand alone hardware players have been able to support the .mp4 container for over 15 years. First with MPEG-4 SP encoded video, then with ASP video. Quickly followed by AVC video and now HEVC encoded video.
And when it comes to audio, the .mp4 container (obviously) supports lossy AAC (in all flavours). But CBR and VBR MP3 works fine too, as does AC-3 and even E-AC-3.
Cheers
Liisachan
25th June 2021, 23:24
When one says "AVI for compatibility", they may mean the container and VfW interface (like when you want to use VirtualDub or AviUtl).
Both CBR and VBR MP3 should be fine in a newer container, except: just do "lame" without -t, and your audio will be delayed by more than one video frame (~ 50ms). Do "lame -t" and still there will be some audio delay (~24 ms), though you can manually correct this before encoding. An AAC encoder qaac has a handy, built-in switch (qaac --no-delay), automatically adjusting the encoder delay so that you can just mux the resulted m4a file.
Katie Boundary
26th June 2021, 21:09
That's bonkers... Stand alone hardware players have been able to support the .mp4 container for over 15 years.
Standalone hardware players are irrelevant to my use cases and workflow.
When one says "AVI for compatibility", they may mean the container and VfW interface (like when you want to use VirtualDub
Bingo
Both CBR and VBR MP3 should be fine in a newer container, except: just do "lame" without -t, and your audio will be delayed by more than one video frame (~ 50ms). Do "lame -t" and still there will be some audio delay (~24 ms)
Pretend for a moment that the AVI files in question were made using Virtualdub's built-in MP3, so both LAME and command-line stuff will not be helpful here. Also the original premiere project files have been corrupted and the Huffy masters have been deleted so I can't redo the audio in LAME.
Liisachan
27th June 2021, 00:35
Pretend for a moment that the AVI files in question were made using Virtualdub's built-in MP3, so both LAME and command-line stuff will not be helpful here. Also the original premiere project files have been corrupted and the Huffy masters have been deleted so I can't redo the audio in LAME. Is it possible that your audio track starts with, or includes, an incomplete MP3 frame? This may happen if you edit your AVI file, by cut-and-pasting.
You can demux the audio, and check it with a binary editor. A good frame should start with 0xFFF (12 consecutive 1s), called sync. If the first 1.5 bytes are not FFF, delete the garbage before the 1st sync, and some tools might become happier to process that MP3 stream.
If it's already MP3 and you don't have the uncompressed version, of course you don't want to re-compress the existing MP3.
Katie Boundary
28th June 2021, 21:40
This may happen if you edit your AVI file, by cut-and-pasting.
The AVI file hasn't been touched since being exported from Virtualdub.
SeeMoreDigital
28th June 2021, 21:47
You really should be encoding and muxing AAC audio into the .mp4 container.
Katie Boundary
3rd July 2021, 19:54
You really should be encoding and muxing AAC audio into the .mp4 container.
Negatory. I've run into problems with programs being unable to decode AAC audio.
hello_hello
3rd July 2021, 21:28
For MP3 audio with problems, you could try loading it into MP3DirectCut and then resaving it as a new MP3.
Foobar2000 has an option under the Right Click/Utilities menu called "Rebuild MP3 stream".
It's supposed to remove any non-MP3 data and (optionally) re-write any existing tags.
FranceBB
3rd July 2021, 23:41
Negatory. I've run into problems with programs being unable to decode AAC audio.
Really? In 2021? O_O Blimey!
What about AC3 in an avi container?
It's still much better than MP3 and it can be compared to AAC in terms of quality, although it requires slightly more bitrate.
At least this is what I used to do in 2006 when I was making SD files with XVID video muxed in avi...
You really should be encoding and muxing AAC audio into the .mp4 container.
Yeah, if it has to be MP4, then AAC-LC is the way to go...
SeeMoreDigital
4th July 2021, 10:39
Negatory. I've run into problems with programs being unable to decode AAC audio.That's ridiculous - They must be some old crappy decoding programs from the dark ages!
Also... Every hardware and software media player I have is able to decode AAC audio streams (in .mp4, .mkv and .m2ts containers). Some can even decode multi-channel AAC audio streams!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.