Hi,

I would like to know the reason for the timescale of 90000 that is inserted into the movie header atom.
Other encoder do insert other timecales (iTunes Store seems to use 600, iTunes seems to use the timecale of the audio track).

The reason I am asking is that Quicktime Player seems to use this timescale multiplied by the duration in the movie header to calculate the playlength of a file. The problem is, that Quicktime seems to use a signed 32bit variable to calculate this (at least on windows). This means that long audio books (longer than about 6 hours) cannot be played by Quicktime Player.

90000 is pretty common AFAIK. It's a good value when you have both audio and video in one file. Using the audio track timescale doesn't really make sense if you also have video, it also gives at most an improvement of a factor 2. 600 seems a little bit low, you probably get problems (again) with the accuracy of the track length.

Yes,with audio/video files it is a good idea but with audio only files (is neroaacenc.exe able to create anything else? ) it does not seem to be necessary.

I know it is not your fault that Quicktime uses signed 32bit integer but I would like to be able to play files longer than six hours with Quicktime Player to have another test application.

Would it be possible to add an option to the encoder that allows to define the timescale of the movie header, or at least set it to the timescale of the one and only track (the audio track)?

I don't think this is a task for the encoder. You could probably do this with mp4box for example.