Trimming changes quality of H.264 1080/60p mov video

Question

Trimming changes quality of H.264 1080/60p mov video
Hi,
I have the following 25 s video (according to QT X inspector):
Format: H.264, 1920 x 1080, Millions
Linear PCM, 24 bit little-endian signed Integer, 2 channels, 48000 Hz
FPS: 59.94
Data Size: 84.7 MB [= file size]
Data Rate: 27.08 Mbit/s
Length: 25 s
After trimming (latest Lion QT version) to 15 s it says:
Format: H.264, 1920 x 1080, Mlllions
AAC, 2 channels, 48000 Hz
FPS: 30
Data Size: 17.9 MB [= file size]
Data Rate: 10.99 Mbit/s
Length: 13 s
I get AAC instead of the original PCM audio format,
I get 30 fps instead of the original 59.94 fps and the
file size and data rate (consequently) appear much too small.
Some weeks ago under Lion (and also still now on another Mac under Snow Leopard)
I didn't have this problem.
Which update caused this and what can I do to get the old, correct trimming behaviour?
Why do I have to "export" now? Previously trimming and saving without quality loss was possible.
Many thanks.

Answer 1

I would call this a bug (or at least a threat), when - after trimming a video - characteristics are modified without confirmation!
I would consider it a "bug" IFF (if and only if) the results were unintentional. Unfortunately, it is likely the engineers/designers knew exactly what they were doing and did so solely in an effort to remove what might be considered confusing options for the novice but which you and I consider options essential to our desired project work flow.
What if I would have trimmed my footage, deleted the originals, and later (in my editing software) noticed the problem?
My assumption here (and it is only an assumption), is that they gave no thought to the possibility that your preliminary "rough" edits might be a prelude to further editing in a multi-step/multi-app work flow. It seems they consider the QT X app edits to be both the alpha and omega in your editing process and only desire to provide the novice with a finished "distribution" product which does not require the novice to make any export decisions.
Last question: Is there a way to determine if the frames had been re-compressed too, or if only every second frame had been ignored? (But in this case shouldn't FPS be 29.97...?)
I would probably compare the QT v10.0 output against the QT v10.1 output using an app like "Dumpster" which will give you the exact frame count for both (i.e., does the latter actually have exactly half the number ± 1, as well as, check the distribution of data for Key/I-frames, etc. For very long clip it should be obvious if the data is being recompressed or merely copied to a new file container by the amount of time this write action takes. Also the file container itself is usually indicative with MOV file containers being used for the "copying" all data tracks and M4V file containers used when data is recompressed, track limited by data type, and finally remuxed to the M4V container.
Last question: Is there a way to determine if the frames had been re-compressed too, or if only every second frame had been ignored? (But in this case shouldn't FPS be 29.27...?)
It would depend on the algorithm used to drop the frames. For instance, the algorithm could simply drop every other frame but maintain the same timing reference or change the reference to provide a preprogrammed maximum 30 fps to maintain compatibility with devices having the 30 fps limitation. Other algorithms might look for "duplicate" frames (i.e., those displaying little or no change) for dropping and apply VFR time referencing to still achieve a 30 (or 29.94) fps target "average."