Enhancement request: allow MP4Modify/MP4Close to not modify max and avg bitrates

[GoogleCodeExporter]

What steps will reproduce the problem?
1. fh = MP4Modify(fn); //fn is iTunes Music file at known fixed bitrate, e.g. 
128000
2. MP4Close(fh);
3. Examine maxBitrate and avgBitrate properties for the file.

What is the expected output? What do you see instead?
Expected output: 128000
Observed output: 129586 (or other random number)

What version of the product are you using? On what operating system?
Version mp4v2-trunk-r355 on Windows XP.

Please provide any additional information below.
I am the developer of aacgain, and I have received complaints from my users 
about the seemingly random bitrates. I work around the problem by patching out 
lines 541-553 of method MP4Track::FinishWrite. It would be nice if there were 
an option on the MP4Close command to prevent the bitrates from always being 
recomputed.

Original issue reported on code.google.com by davelas...@gmail.com on 28 Jul 2010 at 7:55

[GoogleCodeExporter]

Okay, so you want a way to not compute the correct average/max bitrates?  (note 
that those are not "random" numbers, but the actual bitrate of the file)

Original comment by kid...@gmail.com on 9 Aug 2010 at 8:35

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes that is what I want. I agree they are not "random" numbers. But they are 
confusing to a non-technical user who bought a 128KB music file, only to see 
its bitrate change after processing it through aacgain.

Thanks for the help!

Original comment by davelas...@gmail.com on 9 Aug 2010 at 8:44

[GoogleCodeExporter]

okay, I have a slightly different proposal than modifying MP4Close.  What about 
new methods like MP4GetTrackBitRate and MP4SetTrackBitRate?  You'd call 
MP4GetTrackBitRate beforehand to fetch the bitrate, and MP4SetTrackBitRate 
afterward to set the bitrate to the value you desire.  Of course there'd need 
to be calls for average and max, or I'd need to change the existing calls to 
allow you to specify.

I'd rather go this route to avoid adding a plethora of switches to the 
MP4Close() command, and I think technically mp4v2 is in the right here: it's 
specify the actual bitrate, as opposed to the imprecise rate specified by 
iTunes.

Original comment by kid...@gmail.com on 7 Oct 2010 at 2:21

[GoogleCodeExporter]

I agree the new methods are a better solution.

Original comment by davelas...@gmail.com on 7 Oct 2010 at 3:07

[GoogleCodeExporter]

I am the developper of Kid3, an audio tag editor, and I also have received 
complaints that edited files have a different bitrate than unedited files. So I 
am looking forward to seeing the proposed API enhancement.

Original comment by urs.flei...@gmail.com on 2 Jun 2011 at 1:20

[GoogleCodeExporter]

Okay, this should be fixed in r479.  You'll need to update your code slightly 
to take advantage of it--in the MP4Close call is a new flags field.  Passing in 
MP4_CLOSE_DO_NOT_COMPUTE_BITRATE will cause the library to skip generating 
average and max bitrates.  

I decided not to do what I proposed; after looking at it a bit I think this is 
a better method.  Let me know if this works for you, if you have any 
suggestions/feedback, etc.  Thanks.

Original comment by kid...@gmail.com on 26 Jun 2011 at 6:52

• Changed state: Fixed

[GoogleCodeExporter]

I won't have a chance to try the code for a couple of weeks, but I reviewed 
your diffs and they look OK to me.

Thanks for the help!

Original comment by davelas...@gmail.com on 27 Jun 2011 at 5:20