Recortar Audio

¿El audio se sube a algún servidor durante el recorte?

No. El archivo se lee con la File API del navegador y se decodifica con AudioContext.decodeAudioData, la misma API que usa cualquier reproductor nativo — no hay ninguna petición de red involucrada en ese paso. Todo lo que ocurre después (recortar el rango elegido, escribir el WAV de salida) es aritmética pura sobre arrays de muestras (Float32Array) dentro de la misma pestaña. Puedes comprobarlo abriendo la pestaña Red de las herramientas de desarrollador antes de subir el archivo: no aparecerá ninguna petición que lleve el contenido del audio a ningún sitio. Y precisamente porque no hay red de por medio, este paso queda fuera del alcance de la política connect-src 'self' del sitio — la siguiente pregunta explica por qué eso importa para la reproducción.

¿Por qué solo se puede descargar en .wav y no en .mp3?

Es una limitación de licencia, no técnica. Generar un MP3 real exige un códec codificador, y la única opción viable en JavaScript puro es lamejs. El problema es su licencia: LGPL-3.0. LGPL permite combinar una librería con código bajo otra licencia siempre que el usuario final pueda sustituirla — lo cual presupone que existe un artefacto compilado independiente (un .so, un .dll, un objeto separado) que se pueda re-enlazar. Un build hecho solo en JavaScript no tiene eso: lamejs quedaría empaquetado directamente dentro del mismo archivo JavaScript que sirve la página, sin ninguna pieza separable, así que ninguna de las salidas habituales de LGPL aplica aquí. Usarlo significaría o bien re-licenciar esta herramienta bajo LGPL, o mezclar una librería copyleft dentro de un repositorio que se distribuye bajo MIT — ninguna de las dos es aceptable. Por eso la herramienta escribe WAV directamente: no necesita ningún codificador, solo muestras PCM de 16 bits más una cabecera RIFF/WAVE de 44 bytes, escrita a mano en el propio código de la herramienta. Si necesitas el clip recortado de nuevo en MP3, vuelve a codificar el WAV con una herramienta pensada para eso — una app de escritorio, o ffmpeg en la terminal, que sí enlazan un codificador real de la forma que LGPL y GPL esperan.

¿Por qué el archivo .wav pesa tanto más que el original?

Porque no hay compresión de ningún tipo entre medias. El MP3 existe precisamente para descartar la parte de la señal que el oído humano apenas percibe (compresión psicoacústica); el WAV que produce esta herramienta conserva cada muestra PCM de 16 bits tal cual. El cálculo que usa internamente, estimateWavBytes, es aritmética directa: 44 bytes de cabecera más el número de muestras por el número de canales por 2 bytes — sin ningún paso de compresión intermedio. Un MP3 de 3 minutos a 192 kbps pesa unos 4 MB; los mismos 3 minutos como WAV estéreo de 16 bits a 44.1 kHz pesan cerca de 30 MB, siete u ocho veces más. No es un error: es el precio de no perder nada por el camino.

Al escuchar la selección, ¿por qué no se usa un reproductor de audio normal?

Porque la política de seguridad de contenido (CSP) de este sitio lo bloquea activamente. La forma habitual de reproducir un archivo local es crear una URL de tipo blob y asignarla al src de un elemento audio, o hacer fetch() sobre esa misma URL para recuperar los bytes — así es exactamente como wavesurfer.js, la librería que dibuja la forma de onda, carga audio por defecto a través de su método loadBlob. Pero el connect-src de este sitio es 'self' sin ninguna entrada blob:, y tampoco define media-src (por lo que el audio cae al valor por defecto default-src 'self') — así que tanto fetch(blobUrl) como audio.src = "blob:..." quedan bloqueados por Chrome, algo confirmado con un evento securitypolicyviolation real durante el desarrollo de esta herramienta, no una suposición. La solución fue evitar por completo ese circuito: el archivo se decodifica con AudioContext.decodeAudioData, wavesurfer se usa solo para dibujar la onda a partir de los datos ya decodificados (sin pasarle ninguna URL), y al pulsar reproducir el código crea un ctx.createBufferSource() directamente sobre el AudioBuffer que ya está en memoria — en ningún punto de la reproducción aparece una URL blob ni un elemento audio.

¿Hay un límite mínimo de duración para recortar?

Sí, veinte milisegundos (MIN_TRIM_SECONDS). Por debajo de eso, lo seleccionado deja de ser un fragmento de audio reconocible — son apenas unas pocas decenas de muestras PCM, suficientes para producir un chasquido pero no un sonido con sentido. La herramienta prefiere rechazar esa selección con un error explícito (rangeTooShort) antes que devolver un .wav técnicamente válido pero inútil en la práctica. Hay otro detalle menos visible en validateRange: cuando arrastras el borde de la selección hasta el final de la onda, el número de coma flotante a veces queda como 29.999999997 segundos en vez de 30 exactos; sin un ajuste (clamp) al rango [0, duración], esa selección que para ti es perfectamente válida podría rechazarse como si estuviera fuera del clip.

¿Qué formatos acepta la herramienta y puedo recortar varios fragmentos del mismo archivo?

Cualquier formato que el AudioContext de tu navegador sepa decodificar — la herramienta no mantiene su propia lista de "formatos soportados", simplemente le pasa el archivo al navegador y confía en su respuesta; en la práctica eso cubre mp3, wav, ogg (Vorbis/Opus) y m4a/aac en cualquier navegador moderno de escritorio o móvil. Si la decodificación falla, se muestra el error tal cual (decodeFailed) en lugar de adivinar la causa. Y sí, se pueden recortar varios fragmentos del mismo archivo sin volver a subirlo: el archivo original permanece en memoria durante toda la sesión, así que tras descargar el primer .wav basta con arrastrar la región de selección a otro tramo de la misma onda y pulsar recortar de nuevo.