Mp4Chaps --Every Omits Last Chapter Break

[GoogleCodeExporter]

What steps will reproduce the problem?
1. mp4chaps --every 1800 
2. mediainfo

What is the expected output? What do you see instead?
According to mp4chaps --help, the --every option is supposed to insert a 
chapter stop every X seconds.  It does so almost correctly, but omits the very 
last chapter stop.

The example file (mediainfo output attached) is 8 hours and 6 minutes long.   
Mp4chaps --every 1800 (i.e., 30 minutes) should put the last chapter break at 
the 8 hour mark.  Instead it stops at the 7 hour 30 minutes mark.

This behavior is entirely reproducible with every of hundreds of files I've 
tried it with.

While some people may prefer to have a super-long (up to twice the supposed 
length) last chapter in an audio or video file, I suspect most do not and that 
is not what the documentation says.

What version of the product are you using? On what operating system?
Most recent source pulled off the Google Code page, compiled with MSVC under 
Windows 7 x64.

Original issue reported on code.google.com by CarlEd...@gmail.com on 25 Jul 2010 at 11:27

Attachments:

• mediainfo.txt

[GoogleCodeExporter]

I'm not sure what "mediainfo" is, but what sort of output does mp4chaps --list 
give you?

I tried to recreate this with a random file I had lying around, but I didn't 
manage to hit it.

Original comment by kid...@gmail.com on 26 Jul 2010 at 5:10

[GoogleCodeExporter]

mp4chaps --list gives the same output (attached).  I've also attached the 
mp4info output indicating that the file is 29177 seconds long, i.e., over 8 
hours and hence should have a chapter break at the 8 hour mark.  Both of these 
are of a file which immediately previously had "mp4chaps --every 1800" run on 
it.

I am surprised there is a problem reproducing the problem as every one of 
literally hundreds of my audio book files has the same problem.  It seems 
unlikely, but might it be related to the fact that these files are quite large 
(100+ MBytes), quite long (often 8 to 10 hours), and have the .m4b extension 
(used by iTunes to recognize audio books, but content-wise just a regular mp4 
file)?

Original comment by CarlEd...@gmail.com on 26 Jul 2010 at 6:18

Attachments:

• mp4info.txt
• mpchaps-list.txt

[GoogleCodeExporter]

Is it possible that the issue is related to a rounding error?  My example file 
is 29177 seconds long and I asked for chapter breaks every 1800 seconds (i.e., 
every half hour).  29177/1800 = 16.2094444 and mp4chaps creates 16 chapter 
breaks.  However, because the first chapter break is at 0, the fraction should 
always be rounded up, i.e., create 17 chapter breaks in this case.

Original comment by CarlEd...@gmail.com on 26 Jul 2010 at 6:21

[GoogleCodeExporter]

I don't suppose you can share one of these long audiobook files with me 
somehow, just so I can reproduce it?  it seems clear there's a bug, and I'm 
pretty sure I could find it if you could get me one of these files.

Original comment by kid...@gmail.com on 26 Jul 2010 at 7:28

[GoogleCodeExporter]

It's probably a bit large as an attachment here, but if you have a web server 
you could temporarily toss it on, I can download and reproduce.

Original comment by kid...@gmail.com on 26 Jul 2010 at 7:30

[GoogleCodeExporter]

I'd be happy to.  I've legally purchased the relevant audio books, but putting 
a link to my ftp server and login information on a public site may be beyond 
the bounds of fair use.  If you e-mail me at CarlEdman@gmail.com, I'll e-mail 
you the information back.

Original comment by CarlEd...@gmail.com on 26 Jul 2010 at 7:34

[GoogleCodeExporter]

I've created a silent sample file which is both long enough to exhibit the 
problem and small enough to attach here.  Please find it attached.  Again, this 
file is over 8 hours long, so after "mp4chaps --every 1800" it should have a 
chapter break at the 8 hour mark.  It does not.

Original comment by CarlEd...@gmail.com on 26 Jul 2010 at 8:59

Attachments:

• test.m4b

[GoogleCodeExporter]

First, my apologies--I think I did reproduce it, but didn't understand that I 
had, because it's sort of a subtle problem.

Second, this should be fixed in r391--previously the code was tacking on the 
remaining time to the last chapter (resulting in a final "large" chapter, like 
you noted), instead of creating a final small chapter.  I believe a final small 
chapter is more correct, and it actually simplifies the code a bit.

Original comment by kid...@gmail.com on 26 Jul 2010 at 9:51

• Changed state: Fixed

[GoogleCodeExporter]

Thanks, once again, Kidjan!  I'll download the new version tomorrow and give it 
a test drive.

Original comment by CarlEd...@gmail.com on 27 Jul 2010 at 12:27