How much of a media file to keep when trimming it down. More...
Detailed Description
How much of a media file to keep when trimming it down.
Every default here leans the same way: it is always better to keep audio nobody needed than to remove audio somebody did. Trimming is the one operation in this family that destroys information, and the applications that got it wrong – forum threads titled "Minimize Files wrecked my project" are not hard to find – got it wrong by being eager.
Public Attributes | |
| double | handles = 2.0 |
| qint64 | minimumGain = 1024 * 1024 |
| Do not touch a file unless trimming actually saves this many bytes. | |
| double | maximumUsedFraction = 0.9 |
| Do not touch a file whose used region already covers this much of it. | |
| bool | removeOriginal = false |
Member Data Documentation
◆ handles
| double Process::TrimOptions::handles = 2.0 |
Extra media kept on each side of the used region, in seconds.
Users routinely keep a clip's file longer than the clip so they can pull a fade out later, and the first complaint about every trim feature is that it took that away. Two seconds is cheap and covers the common edit.
◆ removeOriginal
| bool Process::TrimOptions::removeOriginal = false |
Delete the file the trimmed one replaces.
Off by default, and it stays useful off: the untrimmed file simply stops being referenced, so it no longer travels with the project when it is archived, while remaining on disk for undo to fall back on. Turning this on is the only part of score's file handling that can lose data.
The documentation for this struct was generated from the following file: