La grabación de Atomos Ninja se ha detenido: el archivo no se abre

La Atomos Ninja, la Ninja V, la Ninja V+, la Ninja Phone (2024), la nueva familia Ninja TX / Ninja TX GO / Ninja RAW (anunciada en 2026) y la línea Shogun, incluida la reciente Shogun Ultra y la Shogun AV-19 montada en rack (febrero de 2026, se envía en marzo de 2026), son el estándar de oro para la grabación externa ProRes, y el estándar de oro para un modo de fallo específico. Cuando la unidad pierde energía a mitad de la grabación (la batería se agota, el adaptador de CA falla, el cable se suelta), la grabación se detiene abruptamente y el archivo en el SSD termina siendo grande, con un aspecto correcto y absolutamente imposible de abrir. Esta página trata sobre ese archivo.

Hemos recuperado muchos de estos. Los patrones son consistentes y la solución se conoce bien. La buena noticia: en nueve de cada diez de estos casos, los fotogramas ProRes reales en el SSD están intactos. Lo que falta son los metadatos del contenedor QuickTime que le indican a tu editor dónde están los fotogramas.

Qué hay en el SSD cuando una Ninja se detiene a mitad de la grabación

Las unidades Atomos graban ProRes (o DNxHR/DNxHD en algunas configuraciones) en contenedores MOV. El contenedor se finaliza en el momento en que presionas «Stop». Si se interrumpe la alimentación antes de ese momento, el archivo tiene este aspecto:

[ftyp]               ← container declaration, intact
[mdat starts here]   ← all your ProRes frames + LPCM audio interleaved
... a few hundred MB to several GB of frames ...
[mdat ends abruptly]  ← no MOOV, no closing atoms

Muchas herramientas compatibles con MOV asumen que «[ftyp]» más un «[moov]» ausente o no analizable significa que todo el archivo es basura. No es así. Los datos de fotogramas que se encuentran en «mdat» son la toma.

Por qué esto afecta específicamente a las unidades Atomos

Las unidades Atomos son populares precisamente porque evitan los límites de contenedor de la cámara: se obtienen tomas más largas, tasas de bits más altas y códecs ProRes/DNx que la propia cámara no puede escribir internamente. La desventaja es que también son un dispositivo separado con alimentación independiente. Si el cuerpo de la cámara está bien pero la batería de la Ninja se agota, la grabación en el SSD nunca se detiene de forma limpia.

Desencadenantes comunes que vemos:

• Agotamiento de la batería NP-F durante entrevistas largas o trabajos documentales.
• Cable D-tap suelto cuando el operador de la cámara se mueve.
• Caída de tensión del adaptador de CA en lugares con suministro eléctrico inestable.
• SSD expulsado mientras la unidad todavía está escribiendo (poco frecuente, pero ocurre con errores de intercambio en caliente).
• Bloqueo del firmware en firmwares Ninja V+ más antiguos: la unidad se reinicia y la grabación se pierde de la misma manera que con un corte de energía.

Dos peculiaridades específicas de Atomos que nuestro motor gestiona

La mayoría de las herramientas de recuperación genéricas devolverán un archivo que casi funciona. El audio suele ser el punto débil. Hay dos razones específicas.

1. PCM en little-endian cuando todo lo demás está en big-endian

Las unidades Atomos escriben el audio PCM como little-endian de 24 bits. El formato MOV de QuickTime es históricamente big-endian. Muchas herramientas de recuperación realizan un intercambio de bytes incondicional al reconstruir la pista de audio, lo que funciona para el audio interno de la cámara, pero produce un audio que suena como estática en los archivos de Atomos. Detectamos el orden de bytes a partir de la distribución real de la muestra y no realizamos el intercambio a menos que los datos nos lo indiquen.

2. Colocación de fragmentos de audio dentro del grupo de vídeo

En el intercalado MOV, los fragmentos de audio se sitúan junto a los fragmentos de vídeo en «mdat». La posición exacta — antes del fragmento de vídeo en el mismo grupo, o después — afecta a la sincronización de la línea de tiempo. Los archivos Atomos requieren que los fragmentos de audio estén al principio del grupo de vídeo; colocarlos al final crea aproximadamente medio segundo de desfase de audio que no se puede corregir con ninguna corrección de estiramiento. Lo descubrimos en una revisión específica del firmware de Ninja V y resultó que se aplicaba a toda la línea.

Si estás utilizando una herramienta genérica de reparación de MP4 y devuelve un archivo con un desfase de audio de ~0,5 s, es casi seguro que eso es lo que ha ocurrido.

Lo que puedes probar tú mismo

1. Conecta el SSD a tu ordenador y copia el archivo del disco antes de hacer cualquier otra cosa. Nunca intentes la recuperación en el SSD de origen: trabaja con una copia.
2. El modo de rescate AtomOS de Atomos. El firmware más reciente tiene una opción de «recuperación de grabación incompleta» que se ejecuta en la unidad. Prueba esto primero: si funciona, habrás terminado en dos minutos. Si no funciona, tu archivo está en nuestro territorio.
3. 'untrunc' (código abierto). Excelente para archivos de Atomos específicamente porque el modo de fallo (truncado, falta MOOV, por lo demás intacto) es exactamente para lo que se creó untrunc. Necesitas un archivo de referencia «bueno» de la misma unidad Ninja con los mismos ajustes de grabación.
4. 'ffmpeg -i broken.mov -c copy out.mov'. No recuperará el archivo, pero te dirá lo que ve FFmpeg.

Si no tienes un archivo de referencia que coincida, untrunc no puede ayudarte. Esa es la razón más común para utilizar un servicio como el nuestro.

Cómo gestiona nuestra recuperación un archivo Ninja

• No se requiere clip de referencia. Extraemos los parámetros del códec del primer fotograma ProRes completo en «mdat». Los fotogramas ProRes tienen su propia anchura, altura y códec four-cc («apcn», «apch», «apcs», «ap4h», etc.). Eso es suficiente para reconstruir un «stsd» válido.
• Todos los tipos de ProRes. Proxy, LT, 422, HQ, 4444, 4444 XQ. El códec four-cc identifica la variante; al resto de la canalización no le importa.
• DNxHR / DNxHD también son compatibles (Ninja y Shogun pueden grabar cualquiera de los dos).
• Audio gestionado correctamente desde el principio (las dos peculiaridades anteriores).
• «co64» para archivos de más de 4 GB, que es lo que acepta la mayoría de las Ninja profesionales.

Qué debes hacer

1. Sube el archivo dañado. Hasta 50 GB. Arrastra y suelta.
2. Aproximadamente 1 minuto después, obtendrás una vista previa gratuita de 5 segundos. Imagen y audio. Puedes desplazarte.
3. Si te parece bien, paga y descarga el archivo recuperado completo. Si no es así, ajusta los parámetros de forma interactiva o solicita una revisión humana sin coste alguno.

FAQ

¿Funciona en Ninja, Ninja V, Ninja V Plus, Ninja Phone, Ninja TX, Ninja TX GO, Ninja RAW, Shogun, Shogun Connect, Shogun Ultra, Shogun AV-19 y Sumo? Sí. El formato de contenedor es el mismo en toda la gama. El códec (ProRes / DNx) y la configuración de audio varían, pero nuestro motor los identifica a partir de los datos.

¿Se admiten las grabaciones ProRes RAW? Parcialmente. Se detectan los fotogramas ProRes RAW, pero a veces faltan los metadatos necesarios para reconstruir la secuencia ProRes RAW completa (información de color específica de la cámara, metadatos del sensor) en los casos de mayor corrupción. Intentamos avisarte rápidamente si no podemos.

Mi Atomos estaba grabando desde una RED / ARRI / Sony Venice. ¿Eso cambia algo? No. El Atomos escribe ProRes/DNx independientemente de la cámara de origen. La recuperación es idéntica.

¿Puedo recuperar solo el audio, no el vídeo? Sí. Deriva el caso después de la carga y pregunta. Podemos extraer solo el audio.

Mi archivo se reproduce durante 30 segundos y luego Premiere/Resolve se bloquea. Modo de fallo diferente (corrupción a mitad del archivo, no falta MOOV). Aún así, se puede recuperar en la mayoría de los casos. Súbelo y el diagnóstico nos dirá de qué patrón se trata.

Relacionado

• Qué significa realmente «MOOV atom not found»
• Corrupción de Atomos Shogun ProRes
• Cómo funciona nuestro motor de recuperación

Sube tu archivo Atomos →