mp4chaps breaks runtimes on larger m4b files

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a long, high quality M4B e.g. 6hrs, Stereo, 32kHz/60kbps. I used the 
Fraunhofer AAC encoder
2. Open in iTunes to confirm Runtime (e.g. 6:11:44)
3. Create corresponding file.chapters.txt
4. Import chapters using -i
5. Load into iTunes and review total runtime - Will now be totally different 
e.g. 126:24:25

What is the expected output? What do you see instead?

The book/chapter marks appear to list correctly, and they jump to the correct 
spot, but the scrub bar/position marker is useless, and barely moves. The 
duration of the file isn't actually changed, the book will stop playing at the 
'correct' time.

What version of the product are you using? mp4chaps - MP4v2 2.0-r477
On what operating system? Windows 7 x64

Please provide any additional information below:

I have successfully bookmarked the same M4B using a different (windows only) 
tool, and it didn't break. However, if I then use mp4chaps to export the 
'working' chapter marks, I get the following:

-----snip-----
D:\Play>d:\Automation\Tools\Windows\mp4chaps.exe -x 2848-001-001.m4b
mp4v2::impl::MP4Atom::ReadAtom: "2848-001-001.m4b": invalid atom size, extends 
outside parent atom - skipping to end of "aART" "" 174616741 vs 7381049
mp4v2::impl::MP4Atom::ReadAtom: "2848-001-001.m4b": invalid atom size, extends 
outside parent atom - skipping to end of "stik" "" 174616741 vs 7381074
mp4v2::impl::MP4Atom::ReadAtom: "2848-001-001.m4b": invalid atom size, extends 
outside parent atom - skipping to end of "⌐too" "" 174616741 vs 7381119
mp4v2::impl::MP4Atom::ReadAtom: "2848-001-001.m4b": invalid atom size, extends 
outside parent atom - skipping to end of "cprt" "" 174616741 vs 7381164
mp4v2::impl::MP4Atom::ReadAtom: "2848-001-001.m4b": invalid atom size, extends 
outside parent atom - skipping to end of "" "mdat" 341850439 vs 174616741
mp4v2::impl::MP4AtomArray::operator []: illegal array index: 4294967295 of 1: 
errno: 34 (c:\users\jnoring\documents\visual studio 
2008\projects\mp4v2\src\mp4ato
m.h,37)
ERROR: File "2848-001-001.m4b" does not contain chapters of type Unknown
-----snip-----

Kind regards,

Geoff

Original issue reported on code.google.com by jukow...@gmail.com on 27 Sep 2011 at 5:57

[GoogleCodeExporter]

Additional Info:

The sample M4B I am using is 713,525,212 samples long. This is over the old 
limit of 650,000,000 samples.

Someone mentions a '64-bit chuck offset switch', but I'm not sure what they 
meant by that :)

Hope that helps shed some light :)

Kind regards,

Geoff

Original comment by jukow...@gmail.com on 27 Sep 2011 at 7:19

[GoogleCodeExporter]

I have never used the Fraunhoffer AAC encoder, but I used to have similar 
problems with the Nero AAC encoder.  The underlying cause was some 32-bit time 
counter with an excessively high scale factor, causing overruns for lengthy 
files (like audio books).  These days I use a simple .bat script to convert 
wavs to m4bs which circumvents this issue and works fine with audio books 10 
hours and longer.  It requires mp4box in addition to the AAC encoder and mp4v2 
tools.

Original comment by CarlEd...@gmail.com on 28 Sep 2011 at 1:28

Attachments:

• wav2m4b.bat

[GoogleCodeExporter]

Thank you for the response Carl,

I will take a look at mp4box and see if its feasible to integrate it with my 
process.

After thinking about the issue, I realized I was using the 32-bit version of 
MP4chaps, and so grabbed a copy of the 64-bet version. Unfortunately, that one 
doesn't work for me at all! :( When I run the Debug version, it throws 'side by 
side' errors, even though I have the VS2010 and VS2008 C++ redistributables 
installed. The 'release' version throws a different error, which I have 
attached.

If my problem can be solved by the x64 edition, I would love to know how to get 
it running :)

Kind regards,

Geoff

Original comment by jukow...@gmail.com on 28 Sep 2011 at 6:13

Attachments:

• mp4chaps-x64-release.png

[GoogleCodeExporter]

There is an error in mp4chap.cpp (mp4v2-trunk-r479).  The fixQtScale() method 
incorrectly checks the sample count as:

    if( INT_MAX < (MP4GetDuration(file) * MP4GetTimeScale(file)) )

MP4GetDuration already returns the sample count (duration in seconds * sample 
rate) so you are multiplying by the sample rate (time scale) twice.  This 
should be changed to:

    if( INT_MAX < MP4GetDuration(file) )

The corrective action is to change the timescale to 1000, which results in a 
file that appears to iTunes to be (sample rate / 1000) times longer than it 
actually is.  I don't know if this works for anyone else, but it doesn't work 
for me.  I would just indicate an error (file too long by xxxx seconds) or 
something and let the user split it up.

Original comment by mike.mcc...@gmail.com on 8 Mar 2012 at 7:43

[GoogleCodeExporter]

I looked at this more carefully, and you're absolutely correct.  MP4GetDuration 
returns the duration in timescale units, so it's definitely multiplying twice.

This should be fixed in r488.  Thanks for the fix.

Original comment by kid...@gmail.com on 10 Mar 2012 at 6:49

• Changed state: Fixed