A gravação da Atomos Ninja parou — O ficheiro não abre

O Atomos Ninja, Ninja V, Ninja V+, Ninja Phone (2024), a nova família Ninja TX / Ninja TX GO / Ninja RAW (anunciada em 2026) e a linha Shogun — incluindo a recente Shogun Ultra e a Shogun AV-19 montada em rack (fevereiro de 2026, com envio em março de 2026) — são o padrão de excelência para gravação ProRes externa — e o padrão de excelência para um modo de falha específico. Quando a unidade perde energia a meio da gravação (a bateria acaba, a alimentação CA falha, o cabo solta-se), a gravação para abruptamente e o ficheiro no SSD fica grande, com aparência normal e absolutamente impossível de abrir. Esta página é sobre esse ficheiro.

Recuperámos muitos destes. Os padrões são consistentes e a correção é bem compreendida. A boa notícia: em nove de cada dez destes casos, os verdadeiros fotogramas ProRes no SSD estão intactos. O que falta são os metadados do contentor QuickTime que dizem ao seu editor onde estão os fotogramas.

O que está no SSD quando um Ninja para a meio da gravação

As unidades Atomos gravam ProRes (ou DNxHR/DNxHD em algumas configurações) em contentores MOV. O contentor é finalizado no momento em que prime parar. Se a alimentação for interrompida antes desse momento, o ficheiro terá a seguinte aparência:

[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

Muitas ferramentas compatíveis com MOV assumem que '[ftyp]' mais um '[moov]' em falta ou não analisável significa que todo o ficheiro é lixo. Não é. Os dados de fotogramas em 'mdat' são o take.

Porque é que isto afeta especificamente as unidades Atomos

As unidades Atomos são populares precisamente porque ultrapassam os limites de contentor da câmara — obtém takes mais longos, taxas de bits mais altas e codecs ProRes/DNx que a própria câmara não consegue gravar internamente. A desvantagem é que também são um dispositivo separado com alimentação separada. Se o corpo da câmara estiver bem, mas a bateria da Ninja acabar, a gravação no SSD nunca terá uma paragem limpa.

Desencadeadores comuns que vemos:

• Esgotamento da bateria NP-F durante entrevistas longas / trabalho documental.
• Cabo D-tap a soltar-se quando o operador da câmara se move.
• Queda de tensão do adaptador CA em locais com energia instável.
• SSD ejetado enquanto a unidade ainda está a gravar (raro, mas acontece com erros de troca em funcionamento).
• Falha de firmware em firmwares Ninja V+ mais antigos — a unidade reinicia, a gravação é perdida da mesma forma que num corte de energia.

Duas peculiaridades específicas da Atomos com que o nosso motor lida

A maioria das ferramentas de recuperação genéricas devolverá um ficheiro que quase funciona. O áudio é geralmente o ponto em que falham. Existem duas razões específicas.

1. PCM little-endian onde tudo o resto é big-endian

As unidades Atomos gravam áudio PCM como little-endian de 24 bits. O formato MOV do QuickTime é historicamente big-endian. Muitas ferramentas de recuperação fazem uma troca de bytes incondicional ao reconstruir a faixa de áudio — o que funciona para o áudio interno da câmara, mas produz áudio que soa como estática para ficheiros Atomos. Detetamos a ordem de bytes a partir da distribuição real da amostra e não trocamos, a menos que os dados nos digam para o fazer.

2. Colocação do bloco de áudio dentro do grupo de vídeo

Na intercalação MOV, os blocos de áudio ficam ao lado dos blocos de vídeo em "mdat". A posição exata — antes do bloco de vídeo no mesmo grupo, ou depois — afeta a sincronização da linha do tempo. Os ficheiros Atomos exigem blocos de áudio no início do grupo de vídeo; colocá-los no final cria cerca de meio segundo de desvio de áudio que nenhuma correção de alongamento corrige. Aprendemos isso numa revisão específica do firmware Ninja V e acabou por se aplicar a toda a linha.

Se estiver a usar uma ferramenta genérica de reparação de MP4 e esta devolver um ficheiro com um desvio de áudio de ~0,5 s, é quase certo que foi isso que aconteceu.

O que pode tentar fazer

1. Ligue o SSD ao seu computador e copie o ficheiro do disco antes de fazer qualquer outra coisa. Nunca tente a recuperação no SSD de origem — trabalhe numa cópia.
2. O modo de recuperação AtomOS da própria Atomos. O firmware mais recente tem uma opção de "recuperação de gravação incompleta" que é executada na unidade. Experimente isto primeiro — se funcionar, estará tudo resolvido em dois minutos. Se não funcionar, o seu ficheiro está no nosso território.
3. 'untrunc' (código aberto). Excelente para ficheiros Atomos, especificamente porque o modo de falha (truncado, MOOV em falta, mas de resto intacto) é exatamente para o que o untrunc foi criado. Precisa de um ficheiro de referência "bom" da mesma unidade Ninja com as mesmas definições de gravação.
4. 'ffmpeg -i broken.mov -c copy out.mov'. Não recuperará, mas dirá o que o FFmpeg vê.

Se não tiver um ficheiro de referência correspondente, o untrunc não pode ajudar. Essa é a razão mais comum para usar um serviço como o nosso.

Como a nossa recuperação lida com um ficheiro Ninja

• Não é necessário um clipe de referência. Extraímos os parâmetros do codec do primeiro fotograma ProRes completo em 'mdat'. Os fotogramas ProRes têm a sua própria largura, altura e codec four-cc ('apcn', 'apch', 'apcs', 'ap4h', etc.). Isso é suficiente para reconstruir um 'stsd' válido.
• Todos os tipos de ProRes. Proxy, LT, 422, HQ, 4444, 4444 XQ. O codec four-cc identifica a variante; o resto do pipeline não se importa.
• DNxHR / DNxHD também suportado (Ninja e Shogun podem gravar qualquer um).
• Áudio tratado corretamente desde o início (as duas peculiaridades acima).
• 'co64' para ficheiros com mais de 4 GB, que é o que a maioria das Ninja profissionais aceita.

O que faz

1. Carregue o ficheiro danificado. Até 50 GB. Arrastar e largar.
2. Cerca de 1 minuto depois, obtém uma pré-visualização gratuita de 5 segundos. Imagem e áudio. Pode deslizar.
3. Se estiver correto, pague e transfira o ficheiro recuperado completo. Caso contrário, ajuste os parâmetros interativamente ou encaminhe para uma revisão humana sem qualquer custo.

FAQ

Isto funciona em Ninja, Ninja V, Ninja V Plus, Ninja Phone, Ninja TX, Ninja TX GO, Ninja RAW, Shogun, Shogun Connect, Shogun Ultra, Shogun AV-19 e Sumo? Sim. O formato do contentor é o mesmo em toda a linha. O codec (ProRes / DNx) e a configuração de áudio variam, mas o nosso motor identifica-os a partir dos dados.

Gravações ProRes RAW — suportadas? Parcialmente. Os fotogramas ProRes RAW são detetados, mas os metadados necessários para reconstruir o fluxo ProRes RAW completo (informações de cor específicas da câmara, metadados do sensor) estão por vezes em falta nos casos de corrupção mais graves. Tentamos informá-lo rapidamente se não conseguirmos.

O meu Atomos estava a gravar a partir de uma RED / ARRI / Sony Venice — isso muda alguma coisa? Não. O Atomos grava ProRes/DNx independentemente da câmara de origem. A recuperação é idêntica.

Posso recuperar apenas o áudio, e não o vídeo? Sim — encaminhe o caso após o carregamento e pergunte. Podemos extrair apenas o áudio.

O meu ficheiro é reproduzido durante 30 segundos e, em seguida, o Premiere/Resolve falha. Modo de falha diferente (corrupção a meio do ficheiro, MOOV não em falta). Ainda recuperável na maioria dos casos. Carregue-o e o diagnóstico dir-nos-á de que padrão se trata.

Relacionado

• O que "MOOV atom not found" realmente significa
• Corrupção de Atomos Shogun ProRes
• Como funciona o nosso motor de recuperação

Carregue o seu ficheiro Atomos →