r/shutterencoder

some errors need to be fixed in timeline - waveform is not correct

some errors need to be fixed in timeline - waveform is not correct

as you can see i got 12 min video and the audio is only 2 min but the waveform is full 12 min ------im telling you because i need to know where the wave ends so i can use cut without re encoding feature to cut easily ---this is best software so for but some issues and also it freezes with 4k and im on 8 gb ram so i guess my fault but at 1080p also little issue ----is there anyway i can cut those unwanted parts without audio in bulk

u/prank100 — 15 hours ago

How to cut frames/scene from a video?

I recently got to know about shutter encoder that it has a function of editing/cutting out scenes from output video. I have .mkv file of an hour of a digital camera video. Now, I want to edit out a minute scene from 3:00 to 4:50 and another scene from 15:00 to 17:30.

I tried reading the website for this process but I'm too dumb to do that? Where to edit? I'm unable to do the edit?

u/not_yourpotato — 2 days ago

Shutter Encoder won't open.

For the past couple of updates, the program hasn't opened on the first try, nor does it open unless run as an administrator. Is anyone else experiencing this?

reddit.com
u/maxxerpro — 4 days ago

Burn in subtitles always out of sync - in sync in preview window only

Incredible program if I could get subtitles to work correctly. Anytime I click add subtitles from an .srt or source, the preview player window plays them in sync, but then after encoding they're always several seconds out of sync. Tested with AV1 and h265 encoding and many different files/subtitle combinations, clip segments, not entire video encoded if that matters.

Is there a way to fix this? AI says it's because the program reads the FPS wrong and rounds up, but that doesn't really make sense if it's in sync in the main clipping preview window before encoding.

This is on Shutter 20.1 64bit, Windows 11. If you need logs or more details, can provide everything.

reddit.com
u/psk_94 — 5 days ago

Questions Shuttter Trasncript

MERCI pour cette nouvelle version de Shutter Transcripteur !

Je fais des transcriptions de chants traditionnels andalous et je suis sidéré de la capacité de transcription de ces chants avec ce logiciel.

Deux remarques : quand on fait une transcription d'une réunion par exemple en mode texte on a deux ou trois mots par ligne. Pourquoi ? comment améliorer ce problème ?

Existe t’il un mode d'emploi entre autre pour connaitre les différences des transcripteurs/traducteurs IA ?

A bientôt et encore merci

Patrick

reddit.com
u/West_Demand6245 — 6 days ago

Editing audio file in shutter coder file will no longer upload to VN video editor

Hi I’ve got a weird one… I notice when I equalize a voice recording in shutter encoder the enhanced file that’s added to my folder will not upload to VN video editor but my original unedited one does. I’m just wondering if anyone knows how to fix this?

reddit.com
u/Maleficent-Pin6061 — 6 days ago

Latest update on linux refuses to install?

Hey. The latest update (20.2.) refuses to install because of:

"The following packages have unmet dependencies:

shutter-encoder: Depends: libflac8 but it is not installable

Depends: libicu70 but it is not installable"

My package manager doesn't even find these packages?

====

OS: Zorin OS 18.1

Kernel: x86_64 Linux 6.17.0-20-generic

DE: GNOME 46.7

Wayland

reddit.com
u/PocketStationMonk — 5 days ago

"SUBTITLES" does not work fine anymore

Hi Paul, since version 20.x I’ve been unable to use the subtitle functions that I’d always used up to version 19.9. Whenever I try to use one, the window asking for the SRT file no longer opens, and when I try to open it manually by clicking on ‘Add Subtitles’, a window with a black background and in French appears. Furthermore, the settings for the old Functions are no longer valid; they aren’t recognised. Windows or Mac – it makes no difference.

reddit.com
u/Key-Award-5938 — 7 days ago

Encoding NVENC with GTX 1060 is faster that 3080

When I was using 2 pc to re-encode some videos, I noticed that my Shitbox-3000™ is WAY faster than my good PC when I use the Nvidia NVENC hardware acceleration or the.

For a video of about 5 min thats 443 mb, I encode it in H.265 NVENC max quality, my Shitbox-3000™ with the 1060 3gb GPU i7-8700 CPU, it encode at ~493 FPS and my good PC which has a rtx 3080, i9-13900K, it encode at about ~40-70 fps with the same settings.

They also both have the latest version of the app (v20.2) and both have the latest Nvidia drivers and windows update.

It's a very weird because the 1060 only has 3GB of Vram and the 3080 has 10GB so it would make sense the the one with more power is faster but no.

If someone knows what's going on and how to fix it, please help me 🥺

u/unpredictable_spoon — 7 days ago

Shutter Encoder Version 20.2 is available!

Highlights:

  • Added "Intel Quick Sync" hardware acceleration for Linux
  • Added 'Identify speakers' option for "Audio transcription" function
  • Improved timecode display with drop-frame videos
reddit.com
u/paulpacifico — 8 days ago

TRIMMING DOESN'T WORK IN 20.X

Hi Paul, since version 20 I haven’t been able to trim a video; every time I press I or O, a 1-frame selection always appears.

reddit.com
u/Key-Award-5938 — 7 days ago

Suppression des curseurs debut fin

Bonjour,

comment supprimer les curseurs Debut/Fin pour obtenir a nouveau l'ensemble de la video. Chaque fois que je recharge la video il garde mes anciens placements.

Désolé si je ne suis pas au bon endroit pour poser cette question qui semble si simple ;-)

Robert

reddit.com
u/Bob37170 — 7 days ago
▲ 4 r/shutterencoder+1 crossposts

Transcoding Variable Framerates to constant without losing quality

tdlr: Variable Frame Rate footage creating ghost clips when exporting through Premiere Pro. Using Shutterencoder to get Constant Frame Rates but now running into questions regarding correct export formats. CBR vs CQ is the question.

I've been downloading footage from National Archives and some of it comes in variable frame rates. This creates issues in Premiere Pro when trying to clip and reexport. Therefore I started using Shutter Encoder to transcode them with Constant Frame Rates. However, I realized I don't exactly know what settings I should be using.

The original file (data from MediaInfo)

Format : AVC

Bit rate : 1 985 kb/s

Frame rate mode : Variable

Frame rate : 60.000 FPS

My current export setup

Format : AVC

Bit rate mode : Constant

Bit rate : 2 500 kb/s

Frame rate mode : Constant

Frame rate : 60.000 FPS

In Shutter Encoder the only settings I change are Constant Framerate with Drop selected

and CBR 2500 (I go slightly higher than the original to ensure I'm not loosing quality without making the filesize larger)

Now the question is using a slightly higher CBR the correct answer or should I go with CQ?

I did some back and forth with the AI dudes and they said to go with CQ 18-21. After digging further I found out that ffmpeg implemented a standard checker from Netflix (VMAF) regarding quality control and it basically came to the conclusion that I made the right choice since I save space.

(I know I should be using ProRes or other editing formats but my M1 Mac can handle interframe codecs just fine so I save a lot of space)

If you want to see the full report here you go:

# H.264 CBR vs. CQ: Editorial Intermediate Encoding Analysis
### National Archives Archival Footage — VMAF Quality Assessment


---


## TL;DR


CBR at 2,500 kb/s and CQ 18 are functionally equivalent on National Archives material. Neither produces frames below VMAF 80. Every CQ value above 18 introduces at least one frame below 80, and the degradation accelerates sharply past CQ 20. The existing CBR workflow is defensible and supported by the data. CQ 18 is a viable fallback for content identified as high-complexity, but it offers no meaningful quality gain over CBR for this class of material.


---


## Background


National Archives digitized footage arrives as variable frame rate (VFR) H.264 at low bitrates (~720×480, ~1,981 kb/s). VFR timing drift causes Premiere Pro to land on fractional frame boundaries at splice points, producing ghost frames and mixed frames at cuts. The established fix is a forced CBR re-encode at constant 60fps before editorial:


```
Source (VFR, ~1,981 kb/s) → CBR 2,500 kb/s / CFR 60fps → Editorial intermediate
```


The question this test addresses: does the CBR ceiling introduce meaningful quality loss relative to a CQ-based approach? And if so, at what CQ value does quality become acceptable?


---


## Test Setup


**Reference:**
 National Archives CFR re-encode — H.264 CBR 2,500 kb/s, constant 60fps, 720×480. This file is the actual source from which all editorial intermediates are encoded, making it the correct ground truth for VMAF comparison.


**Distorted variants:**
 Seven encodes of the same clip, all H.264 CFR at 60fps:


- CBR 2,500 kb/s (workflow baseline)
- CQ 18, 19, 20, 21, 22, 23


**Analysis tool:**
 FFmpeg libvmaf, per-frame JSON logs. Scores parsed with `vmaf_analyze.py` for min, 1st/5th percentile, mean, harmonic mean, and frame counts below broadcast-relevant thresholds of 90 and 80.


---


## Results


```
====================================================================================================
  VMAF ANALYSIS SUMMARY
====================================================================================================
Label                            Min      P1      P5    Mean  H.Mean     Max  WorstFrame     WorstTC         <90         <80
----------------------------------------------------------------------------------------------------
vmaf_CQ18_                     81.25   85.49   86.89   91.08   90.99  100.00        3235 00:01:40:32        1354           0
vmaf_CQ19                      79.44   83.71   85.32   89.93   89.83  100.00        3235 00:01:41:12        1914           1
vmaf_CQ20                      77.47   81.76   83.57   88.67   88.54  100.00        3235 00:01:40:17        2471           8
vmaf_CQ21                      75.47   79.64   81.61   87.33   87.16  100.00        3235 00:01:40:14        2848          49
vmaf_CQ22                      72.85   77.38   79.55   85.76   85.57  100.00        1760 00:00:54:11        3072         230
vmaf_CQ23                      69.86   75.02   77.34   84.17   83.91  100.00        1760 00:00:55:10        3200         647
vmaf_H264                      80.95   84.08   86.16   92.13   91.99  100.00        2707 00:01:24:11        1031           0
====================================================================================================
```


---


## Analysis


### CBR and CQ 18 are statistically equivalent


The CBR and CQ 18 encodes are separated by 0.30 VMAF points at the floor (80.95 vs. 81.25), and by roughly 1 point on the mean (92.13 vs. 91.08). Both produce zero frames below 80. The CBR encode has fewer frames below 90 (1,031 vs. 1,354), likely because it is encoding from and compared against a CBR source — a near round-trip. Neither difference is editorially significant. For National Archives material at this resolution and bitrate, CBR 2,500 and CQ 18 occupy the same quality tier.


### The cliff edge is between CQ 19 and CQ 20


CQ 19 introduces 1 frame below 80 (floor 79.44). CQ 20 introduces 8. From there the count accelerates:


| Setting | Frames below 80 | Floor |
|---------|----------------|-------|
| CBR     | 0              | 80.95 |
| CQ 18   | 0              | 81.25 |
| CQ 19   | 1              | 79.44 |
| CQ 20   | 8              | 77.47 |
| CQ 21   | 49             | 75.47 |
| CQ 22   | 230            | 72.85 |
| CQ 23   | 647            | 69.86 |


This is not a gradual curve. The content has segments that sit right at the encoder's stress threshold, and once CQ crosses 19, failures compound rapidly. CQ 23 produces 647 sub-80 frames — nearly 18% of the clip — against zero for CBR and CQ 18.


### Frame 3235 at 1:40 is the primary stress point


Every variant from CQ 18 through CQ 21 reaches its worst frame at frame 3235, within roughly 18 seconds of each other (1:40:12 to 1:41:12). The convergence of the worst frame across four different encode settings points to a specific content condition at that timecode — most likely a splice point, high-grain burst, or fast motion segment in the source tape. This location should be inspected in Premiere on the CBR source. It functions as a canary: future clips with similar content at similar timecodes will produce the same stress pattern.


### CQ 22–23 introduce a second failure point


At CQ 22 and CQ 23, the worst frame shifts entirely — from frame 3235 to frame 1760 at approximately 0:54. This means two distinct segments in the clip are now failing. The encoder is degraded enough that a second problematic region, which all higher-quality settings handled adequately, begins breaking. Two failure points is qualitatively different from one and indicates the encoder is no longer selectively struggling — it is systematically compromised across the clip.


### A note on VMAF FPS values


The per-log FPS values reported by the VMAF JSON (32.03, 31.91, 32.18, etc.) are inconsistent and do not reflect the actual 60fps source. This is likely a measurement artifact from how FFmpeg reports VMAF throughput rather than source frame rate. It does not indicate a frame rate mismatch in the comparison itself, but the FFmpeg commands used to generate these logs should be reviewed to confirm that reference and distorted streams were explicitly aligned at the same frame rate. If any misalignment existed, the absolute scores may be slightly depressed across all variants — the relative ranking between variants remains valid regardless.


---


## Conclusion


**The CBR workflow holds.**
 For National Archives material at 720×480 and 2,500 kb/s, the existing CBR re-encode produces results indistinguishable from CQ 18 by any VMAF measure that matters for broadcast QC. The theoretical risk of a CBR ceiling degrading editorially critical frames is present in the data — the single-frame floor of 80.95 confirms the ceiling does occasionally bind — but it binds at a level that does not cross the sub-80 threshold where QC flags become likely.


**CQ 18 as a fallback remains valid**
 for clips visually identified as high-complexity before transcode, but the data does not establish a quality gap large enough to justify switching the default workflow.


**CQ 19 and above are unsuitable**
 as editorial intermediates for broadcast delivery on this content class. The sub-80 frames introduced at CQ 19, and the accelerating failure count through CQ 23, represent unacceptable generation loss risk at the intermediate stage.


---


*Test footage: National Archives 19510108 — 2PPCLI Troops, Miryang. 3,554 frames, 720×480, 60fps CFR. Analysis performed June 2026.*
reddit.com
u/JPumuckl — 10 days ago

Move the Shutter Encoder folder to another folder on Mac ?

Hello, how can I configure Shutter Encoder on a Mac so that the folder doesn't appear directly in my finder but in my Videos folder?

Thank you very much

reddit.com
u/PixelPopzz — 11 days ago