erm: CLI open-source elimina muletillas de audio en 2026

Por qué eliminar muletillas del audio es más complejo de lo que parece

1547 palabras de código resolvieron un problema que la mayoría de herramientas cloud resuelven con interfaces bonitas pero enviando tu audio a servidores externos. erm, una CLI open-source lanzada en mayo de 2026 por Doug Calobrisi, elimina automáticamente los «um», «uh» y «er» de grabaciones de voz manteniendo el audio 100% local.

Para founders que producen podcasts, voice notes o contenido audiovisual, esto representa un cambio importante: privacidad total sin sacrificar automatización. El mercado de edición con IA en 2026 está dominado por SaaS como Descript, Adobe Podcast y OpusClip, que ofrecen eliminación automática de muletillas pero requieren subir tus archivos a la nube.

Los tres problemas que la mayoría ignora

El enfoque naive parece simple: transcribe con timestamps a nivel de palabra, identifica tokens como «um» y «uh», corta esos rangos con ffmpeg. Eso te lleva solo al 60% del resultado, y el audio final suena peor que el original.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Whisper omite muletillas en la transcripción. El modelo de OpenAI, dejado solo, edita los fillers porque la mayoría de sus transcripciones de entrenamiento son prosa limpia. No hay token «um» que coincidir en primer lugar.

Cortar en un punto arbitrario produce un click audible. Un splice en el waveform en cualquier instante (casi nunca en cero) deja un step que el oído detecta como un click.

El ruido de fondo no coincide entre cortes. Cada habitación tiene un «silencio» ligeramente distinto. Empalmar dos casi-silencios produce un shift faint que se escucha en cada edición.

La mayor parte del código de erm es resolver exactamente estos tres problemas, no la detección básica.

Los cuatro pases de detección que marcan la diferencia

Pase 1: Whisper con word-level timestamps. Erm usa faster-whisper de SYSTRAN, una reimplementación varias veces más rápida que la referencia original. El default es el modelo medium.en, pero para detectar fillers vale la pena usar large-v3: es notablemente mejor captando muletillas y vale el compute extra.

Pase 2: Gap fillers. Si hay una pausa inusualmente larga entre dos palabras transcritas (más de 350ms por default), erm verifica si alguien está haciendo sonido durante esa «pausa». Si hay un chunk de voz dentro de lo que Whisper marcó como silencio, es un filler que Whisper eliminó completamente. Realmente los droppea: ningún token, solo un hueco en el transcript donde había un «um».

Pase 3: Fillers escondidos dentro de una palabra. Whisper a veces pega un filler a una palabra adyacente, así que «in, uhhhhh» vuelve como un solo token in. Erm mira palabras largas de un solo token, las divide en dips breves del audio, determina qué chunk es la palabra real (basado en cuánto debería tomar pronunciarla) y trata el resto como filler.

Pase 4: Palabras que duran demasiado. Si una palabra dura mucho más de lo que su texto podría plausiblemente tomar, el tail end es sospechoso. Erm escanea el tail por sonido voiced y opcionalmente hace un pitch test: ¿el chunk sospechoso suena como alguien sosteniendo una vocal («uhhhhh») o como alguien hablando lento? Una vocal sostenida tiene una forma acústica steady y simple; el speech real cambia constantemente. El pitch test evita recortar hablantes lentos.

Refinar los cut points: de 60ms a zero-crossing

Un cut exactamente en t = 1.234s aterriza donde el waveform esté en ese instante, casi nunca en cero. Stitching dos puntos arbitrarios deja un step = click audible.

Dos fixes pequeños, en orden:

  1. Cada endpoint de cut puede slidear hasta 60ms para aterrizar en el spot más quieto cercano. Si hay un lull momentáneo justo antes o después del cut point original, slide ahí. El slide está bounded para no cruzar hacia una palabra vecina.

  2. Desde ese quiet spot, el endpoint snappea al nearest moment cuando el waveform cruza exactamente por cero. Dos zero points stitched together producen un waveform continuo sin step, sin click.

Limpieza de fragmentos cortos: si dos cuts adyacentes dejarían un sliver de audio menor a ~120ms entre ellos, el sliver se mergea en un cut más grande. Un fragmento tan chico no sobrevive el smoothing de ambos lados y solo suena como un blip.

Splicing con crossfade adaptativo y room tone

FFmpeg hace el stitching usando un crossfade. En vez de buttar dos piezas de audio juntas, las overlapea brevemente y fadea una out mientras la otra fadea in. Eso smootha cualquier mismatch restante.

El trick es el largo del overlap. Un largo fijo (la mayoría de tutoriales dice 80ms) suena mal de ambas formas: cuts cortos se smean juntos, cuts largos todavía popean. Erm escala el largo al tamaño del cut: un clip chiquito de «uh» recibe un crossfade corto, un «ummmmm» largo recibe uno más largo. Hay un floor y ceiling (50ms a 120ms), y el crossfade nunca puede reachear hacia atrás cruzando el start de una palabra real.

Room tone: el fix dumb que funciona. Encontrar un stretch quieto en la grabación original (un piece real de «esta habitación cuando nadie habla») y looppearlo debajo de todo el output a volumen bajo. Ahora el background es idéntico en todos lados porque es el mismo loop en todos lados. Cualquier mismatch pequeño en cada splice queda cubierto por el steady tone sitting on top.

El denoiser sneaky: cuándo aplicarlo importa

FFmpeg tiene un noise reducer built-in, pero denoising smootha los detalles (volume bumps y pitch wiggles) que los detectores usan para encontrar fillers. Importa CUÁNDO lo haces.

Erm tiene cuatro modos:

| Modo | Detection mira | El output se corta de |
| — | — | — |
| none | el original | el original |
| pre | una copia denoised | la copia denoised |
| post | el original | el original; denoised al final |
| hybrid | el original | una copia denoised |

hybrid es el default y el que querés: detection corre en el audio original (para ver todos los cues), pero los cuts reales vienen de una copia clean, denoised (para que los splices suenen nice).

pre parece sensato pero es la peor opción, porque correr los detectores en audio denoised esconde exactamente lo que están buscando.

Validación end-to-end

Audio renders pueden breakear de formas sutiles, así que hay un subcomando validate:

uvx erm validate input.wav cleaned.wav --cuts cuts.json

Corre tres checks: el output file abre, el output es más corto que el input por roughly el total length de los cuts, y cuando transcribís el cleaned file de vuelta a texto, no vuelven fillers. Ese último es el útil: es end-to-end, te dice que la tool hizo lo que claimó.

Qué no toca (y por qué importa)

Deja intactos «like», «you know» e «I mean». Suenan como fillers pero están doing real work en la sentence, y cortarlos automáticamente cambiaría lo que alguien dijo. La regla que sigue erm: solo remover cosas que son sound, no language.

Tampoco toca repeated words, false starts o long thinking pauses. Esos no son noise on top del speech; SON el speech, solo más messy de lo que el speaker quisiera. Limpiarlos es una decisión editorial sobre qué take keep, y erm no tiene opinión sobre eso.

Alternativas cloud vs local: el panorama en 2026

El mercado de edición con IA para creadores en 2026 está mucho más centrado en apps cloud con interfaz que en utilidades CLI puras. Lo más realista para un flujo local es combinar ASR local como faster-whisper con un script que detecte y corte rellenos.

OpusClip ofrece una función explícita para eliminar muletillas automáticamente en vídeo/audio, detectando palabras como «eh», «em» y «ya sabes», con prueba gratis y planes de pago. Es la alternativa cloud más directa al enfoque de erm.

Descript y Adobe Podcast dominan el espacio SaaS de edición asistida por IA, pero siguen siendo principalmente plataformas cloud con coste recurrente y dependencia de servidores externos.

La diferencia crítica: en el ecosistema open-source no existe una CLI madura y ampliamente adoptada que elimine muletillas tan directamente como las soluciones cloud. Erm llena ese vacío para creadores técnicos que priorizan privacidad y control.

| Enfoque | Ejemplos | Ventajas | Limitaciones |
|—|—|—|—|
| Cloud / SaaS | Descript, Adobe Podcast, OpusClip | Más automático, menos configuración, UX simple | Coste recurrente, dependencia de nube, control fino limitado |
| Local / open-source | erm, faster-whisper, scripts propios | Privacidad, coste bajo, automatizable por CLI | Requiere montaje técnico |
| Híbrido | transcripción local + postprocesado | Mejor equilibrio para creadores técnicos | Necesita pipeline propio |

Qué significa esto para tu startup

Si tu equipo produce contenido audiovisual regularmente (podcasts, demos de producto, training interno, webinars), la elección entre herramientas cloud y locales tiene implicancias directas en costo, privacidad y escalabilidad.

Para founders en LATAM y España: el acceso a herramientas enterprise como Descript puede ser limitado por costos en USD. Una solución open-source local como erm elimina esa barrera y permite automatizar sin depender de suscripciones mensuales.

Acciones concretas que podés implementar:

  • Si ya usás ffmpeg y tenés conocimientos técnicos: instalá erm con uvx erm input.wav y probá el modo --dry-run primero para ver qué cortaría antes de renderizar. Necesitás tener ffmpeg y ffprobe en tu PATH (brew install ffmpeg en macOS).

  • Si priorizás velocidad sobre privacidad: evaluá OpusClip o Descript para flujos rápidos donde el volumen de contenido justifica el coste mensual. Usalos para contenido público y reservá herramientas locales para material sensible o interno.

  • Si escalás a equipo: considerá un pipeline híbrido donde la detección corre local (con faster-whisper) pero la edición final se hace en una herramienta con mejor UX para no-técnicos del equipo.

  • Para podcasts con invitados: la validación end-to-end de erm (validate subcommand) te asegura que el output final no tiene fillers residuales antes de publicar, ahorrando horas de revisión manual.

El insight clave: la automatización de audio no es solo «cortar lo que sobra». Las herramientas que ignoran los detalles técnicos (zero-crossing, room tone, crossfade adaptativo) producen resultados audiblemente peores. Invertir en un pipeline bien diseñado ahorra más tiempo del que gasta en configuración inicial.

Conclusión

Erm demuestra que resolver un problema aparentemente simple (eliminar muletillas) requiere entender profundamente la acústica del speech, no solo aplicar transcripción + corte. Para founders que valoran privacidad, control y coste marginal bajo, las herramientas CLI open-source como esta representan una alternativa viable a los SaaS dominantes en 2026.

La elección no es binaria: podés usar cloud para velocidad en contenido público y local para material sensible o flujos de alto volumen donde las suscripciones se vuelven prohibitivas.

Fuentes

¿te gustó o sirvió lo que leíste?, Por favor, comparte.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Daily Shot: Tu ventaja táctica

Lo que pasó en las últimas 24 horas, resumido para que tú no tengas que filtrarlo.

Suscríbete para recibir cada mañana la curaduría definitiva del ecosistema startup e inversionista. Sin ruido ni rodeos, solo la información estratégica que necesitas para avanzar:

  • Venture Capital & Inversiones: Rondas, fondos y movimientos de capital.
  • IA & Tecnología: Tendencias, Web3 y herramientas de automatización.
  • Modelos de Negocio: Actualidad en SaaS, Fintech y Cripto.
  • Propósito: Erradicar el estancamiento informativo dándote claridad desde tu primer café.

📡 El Daily Shot Startupero

Noticias del ecosistema startup en 2 minutos. Gratis, cada día hábil.

Share to...