Right, certain (only a very small proportion of the whole) avi files were wrongly identified and creqed by aom 0.5.5.238 as having very short lengths (less than 10 second). I don't think petri has found a cause yet, I don't have any of these files myself to examine the headers, and there's no obvious link between them. If you have any of these files (or even better encoded one of them) and can shed some light on the issue, it'd probably be a big help.
http://anidb.info/f152756
http://anidb.info/f157949
http://anidb.info/f159548
http://anidb.info/f161015
http://anidb.info/f126774
http://anidb.info/f148905
http://anidb.info/f151077
http://anidb.info/f89759
http://anidb.info/f135746
http://anidb.info/f147739 <- Akazukin Chacha ep 2, presumably the i! people know the encoder and can ask questions.
http://anidb.info/f162079
http://anidb.info/f152712
http://anidb.info/f140702
http://anidb.info/f140389
http://anidb.info/f142043
http://anidb.info/f143728
http://anidb.info/f140722
http://anidb.info/f45106
http://anidb.info/f149038
http://anidb.info/f143632
http://anidb.info/f152738
http://anidb.info/f156528
http://anidb.info/f2818
^this one is different. aom creqed a length of 4:08:27, which seems wrong to me, but could be a file-specific error.
Admins: feel free to edit this post to add links to files.
Rar
Dodgy avi files
(This will probably be utterly useless since I know nothing about encoding...)
I compared a couple of those files to ones that show the length correctly -- for example Beck 24 (correct length) <-> Beck 25 (2 seconds), and didn't notice any major differences in the headers. Found out nothing with VirtualDubMod either.
However, GSpot reports the 'Stream Type and A/V Interleave' of those supposedly <10 sec long files (Beck 25, Buzzer Beater 9 & 11-13) as:
Type: OpenDML AVI, "rec list" style
...whereas the ones that have correct length (Buzzer Beater 1-8 & 10, Beck 1-24 & 26) are reported as:
Type: OpenDML AVI
That's the only difference between those two groups that I could see. Probably not significant, but I thought that I should tell about it just in case... -_-;
I compared a couple of those files to ones that show the length correctly -- for example Beck 24 (correct length) <-> Beck 25 (2 seconds), and didn't notice any major differences in the headers. Found out nothing with VirtualDubMod either.
However, GSpot reports the 'Stream Type and A/V Interleave' of those supposedly <10 sec long files (Beck 25, Buzzer Beater 9 & 11-13) as:
Type: OpenDML AVI, "rec list" style
...whereas the ones that have correct length (Buzzer Beater 1-8 & 10, Beck 1-24 & 26) are reported as:
Type: OpenDML AVI
That's the only difference between those two groups that I could see. Probably not significant, but I thought that I should tell about it just in case... -_-;
Well, there is a theme there... A number of the files appear to be from DB, I only have one of them at the moment and according to GSpot it is made by Windows Movie Maker 2.1.
That means that it is a Naturdo Speed Subber using a M$ encoder, what do you expect???
GSpot gets the time right, but has a ? for the bitrate... MPC is the only program that I have that has complete information.
That means that it is a Naturdo Speed Subber using a M$ encoder, what do you expect???
GSpot gets the time right, but has a ? for the bitrate... MPC is the only program that I have that has complete information.
-
My Aching Thorax
- Posts: 1
- Joined: Wed Oct 29, 2003 4:27 am
<Warning tag on. Tipsy McStaggger attempts to offer info while totally plastered. Big mistake on TM's part!>
I'm not sure if this problem has been resolved but I'll add a bit of info anyway. I downloaded one of the problematic files and examined the riff chunks earlier today. The example I picked indicated it was an Open-DML extension (as pointed out by others). The frame count yielded the same sub ten second results. Skipping a bunch of Open-DML specs crap that I read I'd suggest taking a look at the STRH chunk and examining the data length field (dwLength). The results should be a closer to home.
<warning tag off... Tipsy McStagger doesn't care!>
I'm not sure if this problem has been resolved but I'll add a bit of info anyway. I downloaded one of the problematic files and examined the riff chunks earlier today. The example I picked indicated it was an Open-DML extension (as pointed out by others). The frame count yielded the same sub ten second results. Skipping a bunch of Open-DML specs crap that I read I'd suggest taking a look at the STRH chunk and examining the data length field (dwLength). The results should be a closer to home.
<warning tag off... Tipsy McStagger doesn't care!>
http://anidb.info/perl-bin/animedb.pl?s ... .id=181972
<pelican> Hmm, my script produces the same length; I guess I need to investigate
<rar> does it say at the end of the video file if played < 2 goto 1:
<pelican> ...the header says that it's got three times as many frames as it has
<pelican> Oh, forgot to tell you the correct length
<pelican> 1:22:49
<rar> round or floor?
<pelican> Round
<pelican> (They happen to be the same in this case though)
<pelican> (I do always round, you know)
<rar> checkin' just checkin'
<pelican> My script rounds too :)
<pelican> ...however I'll have to write that complete parser one day :/
<pelican> The header's can't be relied on, it seems
<pelican> *headers, damn it
Rar
<pelican> Hmm, my script produces the same length; I guess I need to investigate
<rar> does it say at the end of the video file if played < 2 goto 1:
<pelican> ...the header says that it's got three times as many frames as it has
<pelican> Oh, forgot to tell you the correct length
<pelican> 1:22:49
<rar> round or floor?
<pelican> Round
<pelican> (They happen to be the same in this case though)
<pelican> (I do always round, you know)
<rar> checkin' just checkin'
<pelican> My script rounds too :)
<pelican> ...however I'll have to write that complete parser one day :/
<pelican> The header's can't be relied on, it seems
<pelican> *headers, damn it
Rar
