Mirror of forum.nim-lang.org

13517 :: Auto-Editor: Efficient media analysis and rendering

• WyattBlue (orginal) [2025-11-24T06:23:43+01:00] view original

  Auto-Editor is a CLI tool that cuts out the silence in video/audio files.

  Auto-Editor was originally written in Python, however, Python is slow and it's easy to make mistakes in C extensions. Nim is very attractive to me because it has system-language performance and powerful high-level conceptions in scripting languages.

  Before even considering rewriting to a systems language, I transitioned from untyped Python to typed Python (type annotations check with mypy). Then I rewrote the program in Nim from scratch, submodule by submodule.

  Is there some semantic difference between Typed Python and Nim, yes, but it's still 80% the same. This fact, as well as Auto-Editor not being a ginormous project, meant that the rewrite was fast, and I didn't have to write Python-to-Nim bindings.

  Basic example:

  auto-editor video.mp4

  This cuts out the silences. You can adjust the silent threshold:

  auto-editor video.mp4 --edit audio:-20dB

  You can even set custom actions:

  auto-editor video.mp4 --when-silent speed:2.5 --when-normal speed:1.5

  This is only scratching the surface, so check out the GitHub and Docs too.

---

• PMunch (orginal) [2025-11-24T13:42:13+01:00] view original

  This is very cool! Do you have any benchmarks for untyped Python vs. typed Python vs. Nim? Would be interesting to see as a real-world example.

---

• WyattBlue (orginal) [2025-11-24T20:12:42+01:00] view original

  typed Python is just as slow as untyped Python, it just helps catch errors and makes refactoring faster.

  Rendering can be up to 2x faster. Analysis can be 8-10x faster.

  running example.mp4 is ~72% faster on my machine.

---

• dlesnoff (orginal) [2025-11-25T18:00:34+01:00] view original

  In the install section linked in your readme.md, I see installation instructions for your old Python script. I see a .nimble file. Is Atlas usable with your repo?

---

• WyattBlue (orginal) [2025-11-25T18:08:56+01:00] view original

  Using pip is legacy, I'll get rid of it by 2026. What I want is "auto-editor" being available on package managers like Brew, instead of making users download Nim specific pms.

---

• erayzesen (orginal) [2025-11-26T08:25:58+01:00] view original

  Great project, and the cause-and-effect reasoning behind moving it to Nim makes perfect sense. Congratulations.

---

• Hobbyman (orginal) [2025-11-26T19:02:16+01:00] view original

  I like the pauses and silences in audio en video. I deplore these products that cut out all silences, as if people are no more allowed to think or doubt a little bit. Its sad. I assume its all about marketing and modern influencer who wants to make a living that way. Maybe scientists have concluded that X micro-seconds of pause cause Y people to leave the video, thus decreasing advertisement income. Its a saddening tendency to cut out all doubt and create a facade of certainty and self-confidence..

---

• PMunch (orginal) [2025-11-26T21:25:05+01:00] view original

  There's certainly a middle ground though. One thing is lots of jump cuts and no two seconds where nothing happens. Another is watching a video and wondering if if froze because the host just spent a solid ten minutes just staring into their screen without any movement. Being transparent about doubt is fine, but sometimes you want to see progress.

---

• PMunch (orginal) [2025-11-26T21:26:29+01:00] view original

  Those are pretty good numbers, especially as I assume you might be calling out to a C library for at least some of the processing. I noticed that you also mention improving the architecture, do you think that made a huge difference?

---

• WyattBlue (orginal) [2025-12-02T04:22:59+01:00] view original

  The biggest architectural improvement was cutting out PyAV as a middleman. This helped with developer velocity because I wasn't subject to their release schedule. It also helped with binary size because I could ship only what auto-editor needed.

---

• Zoom (orginal) [2025-12-03T13:28:08+01:00] view original

  The project looks interesting and I had it bookmarked already but haven't got a chance to use yet.

  Currently Readme doesn't list all of the functionality and makes an impression of a less capable tool than program's --help. The first question popping up after going over it is what's the value proposition compared to ffmpeg's silencedetect/silenceremove [1]?

  The second is what's the strategy for detecting silence stretches to cut.

  • Is it strictly threshold based?
  • Do you measure the peak levels or some loudness average (RMS/LUFS-S)?
  • Does it aim to work with spoken word? If it does, do you apply any filtering before measuring to reduce false positives?
  • Are the min/max limits for periods to cut configurable?
  • How the detector deals with panned/multichannel audio?

  I only see a single option --margin to configure the actual detection, and if it's indeed so, I doubt it's ready to be widely used outside of specific author's workflow.

  I like the pauses and silences in audio en video.

  This tool has an option to speed up silent parts, not just skip them, it's sensible for editing raw or unscripted talks/dialogues.

---