Quicktime (FAIL)

!http://i46.tinypic.com/2nvn6f.gif!






"I consider this a MAJOR bug"

Did you file a bug report?





!http://i51.tinypic.com/9bkxeq.gif!

Anyone experience a similar issue and actually have a REAL solution. I just wasted a week editing/encoding files for a client only to find out it was all in vain due to these issues in Quicktime.

The "non-destructive" nature of the QT 7 Pro "Save" menu option to trim content is well documented. The "real" solution is to use the "Save As..." option to ensure a new file container is created to which only the trimmed data is copied. Alternately, "trimmed" content can be exported (i.e., re-compressed) which also writes the data to a new or replacement file contained.

When you play this in Quicktime or iTunes, everything is dandy. If you attempt to play this file using any other MP4 player (note: I tested this on over 25++ players of various platforms and devices) not only does the edited clip still exist (can you say Atom elst?) the audio is now out-of-sync with the video.

The Apple media players use the internally "saved" references that point to trimmed content "in" and "out" points for playback. Other media players tend to use the "in" point for playback but use the "end of file" as the "out" point for playback.

Perform steps 1 & 2 using Quicktime and as a final step select 'Export' using 'passive mode' for both the Audio and Video.

Not sure what you mean by "Export using passive mode" here.

"non-destructive"? I see this as more of a Privacy/Security risk, if anything... This is a major issue considering customers trust this software to "trim" what they intended remove, not just hide it. This is the equivalent of a PDF embedding the clipboard "cut & paste" contents into the file.

This is not an issue for those who understand the difference between the non-destructive nature of saving changed pointers within the original file container which otherwise contains all of its original data and the destructive method of creating a completely new container and only copying the actual data you wish the new file to contain. This is the same difference in strategy as used to delete a file which merely marks the hard drive's VTOC and a secure file deletion which not only changes the VTOC but also writes zeros to the data sectors to ensure the original file data cannot be recovered.

After rigorous testing I have found that almost all of the players, with exception of Apple created products, do this. This includes VLC, SimpleMovieX, FfmegX, the list goes on and on...

I do not disagree with you here. I merely point out that these other players are not programmed to use the internal pointers which tell QT players where playback is now supposed to begin and where it is now supposed to end. The fact that you or others users choose to use a "short cut" strategy for saving modified playback reference pointers rather than securely deleting unwanted data is a personal choice and not something forced on users.

When exporting the document using "Export to MP4" there is an option to preserve the output quality called "passive mode"... Quicktime > Export > to MP4 > Click on Options > Select "passive mode" for both Audio and Video.

On my computer this option is called the "Pass through" option and, by definition, passes the original video track data to the output file unchanged and "unedited." So the output you are getting here is just what you asked for when you selected this option setting.

What should take place is the QT Atom "elst" should be cleared on Export. This is not the case as a simple re-encode with Handbrake will reveal the so called "trimmed parts" of the file... This is still an EPIC FAIL on Apple's part.

Not so. There is no "re-encode" action when the "Pass through" ("Passive Mode") option is used. The problem appears to be one of not properly understanding the options available and using the work flow that accomplishes what you actually want done.

If consumers actually knew that information they intended to remove still existed within the file and was easily accessible by others there would be outrage over privacy concerns.

Experienced users are well aware of what is going on. Even novice users have noted that files sizes do not change when making "non-destructive" trims and ask why... making this a periodically reoccurring topic. (Although not usually with such emphasis on the security aspects.)

I failed to note in the post above that the "Save As" solution doesn't work either. The issue still exists.

It works fine on my system. What is not clear from your listed steps above is whether or not you apply the "Trim to Selection" Edit menu option before invoking the "Save As..." option. Failing to do so will, of course, simply save the entire file, with all of the original data and the "in" and "out" playback reference pointers to the new MOV file container. (I.e., this accomplishes the same thing as simply using the "Save" option but unconditionally placing the data in an MOV file container.)

Wouldn't it be better to just remove the trimmed contents altogether?

Yes, if that is what you want to do. My question is, "Why do you use a work flow that does not 'remove' the trimmed content if that is what you want done?" Both options are available to QT 7 Pro users. Why process the file in a manner that results in the retention of data you don't want kept and then complain about it? Why not create a secondary file that only contains the content you want retained, securely delete the original file, and then use/distribute the secondary as desired/needed, thus, alleviating your security concerns?

Actually, when viewed in Quicktime the pointer has actually changed in the new output. But when you re-encode the file using an editor outside of an Apple product the "trimmed" contents re-appear.

Not if you process the file properly. When edited properly, only the "trimmed" data is retained. You can verify this by checking the files size to veify that data has been removed and/or viewing the file in any of the "over 25++ players" you previously tested to verify the deleted data can no longer be accessed. If I have a chance later today, I will create a "quickie" tutorial which demonstrates both the process and the results.

Please explain the options available. Based on my testing the only option is to export (re-encode) which results in loss of quality.

If your goal is to create a file with content physically trimmed and having the original quality, then don't re-encode or use the "Pass through" option--use the "Save As..." option instead. If the data must then be re-wrapped in an MP4 file container, then you can use the "Export Movie to MPEG-4" and "Pass through" option or simply use MPEG Streamclip to place the "already trimmed file" data in the MOV file container into an MP4 file container. The drawback with either of these approaches is that only the MPEG-4 or H.264 video and AAC audio data can be re-wrapped. Extraneous data tracks (e.g., text, chapter, 'tween, etc.) will not be retained.

The average consumer just wants to edit their videos and has no idea what is going on in the background - ie: blindly trusting the application to do what is advertised.

Unfortunately, this is true. Thankfully, when user expectations are not realized, many "average consumers" come here to learn why things are not working as they think the should. In most cases, it is simply a matter of changing the work flow to achieve the desired results and correct misconceptions as to how QT 7 Pro works. In a small number of cases, it is a "real" problem with no evident workaround. (For instance, the Snow Leopard emplementation only offers the "non-destructive" option since the "destructive" option appears to reveal a "bug" which causes the final file to never be written/made visible to the Finder.)

I assume you are testing this using an Apple certified product.

For Leopard based work flows I use an older PPC G5 2.0 DP platform.

Try this...

Once again, your work flow appears flawed. Try the following...
1. Open a file in Quicktime
2. Set "in" and "out" points in the progress bar
3. Use the "Trim to Selection" Edit menu option to reduce the progress bar display to the trimmed data only
4. Using "Save as" create a new a self-contained movie (you can even use a unique file name)
5. Take the file output and re-encode it using Handbrake (or test it for access with one of the other players)

If you want to use a "Cut" or "Copy" work flow, the do the following...
1. Open a file in Quicktime
2. Set "in" and "out" points in the progress bar for the content you wish to retain
3. Use the "Cut" or "Copy" Edit menu option to copy the selected data to the clipboard
4. Create a new player and paste ("Command-V") the selected clipboard data to the new player
5. Using "Save as" or "Save" create a new a self-contained movie (you can even use a unique file name) from the newly created player
6. Take the file output and re-encode it using Handbrake (or test it for access with one of the other players)

If you want to use a "Delete" work flow, try the following...
1. Open a file in Quicktime
2. Set "in" and "out" points in the progress bar for the segment you wish to remove
3. Use the "Delete" Edit menu option to remove the unwanted segment
4. Repeat steps 2 and 3 untill all unwanted data has been removed
5. Using "Save as" or "Save" create a new a self-contained movie from the data still retained in the player progress bar
6. Take the file output and re-encode it using Handbrake (or test it for access with one of the other players)

I have tested this with over 200 files. Same results.

If your test intructions list was complete, then your work flow was incomplete and any of the above algorithms should accomplish what you want.

Off the present topic, but...

"This is the same difference in strategy as used to delete a file which merely marks the hard drive's VTOC and a secure file deletion which not only changes the VTOC but also writes zeros to the data sectors to ensure the original file data cannot be recovered."

VTOC? Do they still call it that? I haven't even seen that term since back when I was still doing random-access text file programming for DOS 3.3 in Applesoft...! 🙂

--Dave Althoff, ][.

VTOC? Do they still call it that?

Sorry, guess my age was showing... However, whether you call it a Volume Table of Contents, File Allocation Table, or simply "the Catalog," I assume most people understand the data structure/control function to which I was referring.