Formato de arquivo Au
O formato de arquivo Au é um formato de arquivo de áudio simples introduzido pela Sun Microsystems. O formato era comum nos sistemas NeXT e nas primeiras páginas da Web. Originalmente, era sem cabeçalho, sendo simplesmente dados codificados em μ-law de 8 bits a uma taxa de amostragem de 8.000 Hz. O hardware de outros fornecedores geralmente usava taxas de amostragem de até 8.192 Hz, geralmente múltiplos inteiros de frequências de sinal de clock de vídeo. Os arquivos mais recentes têm um cabeçalho que consiste em seis palavras não assinadas de 32 bits, um pedaço de informação opcional que é sempre de tamanho diferente de zero e, em seguida, os dados (no formato big-endian).
Embora o formato agora suporte muitos formatos de codificação de áudio, ele permanece associado à codificação logarítmica da lei μ. Essa codificação era nativa do hardware SPARCstation 1, onde o SunOS expunha a codificação a programas aplicativos por meio da interface de arquivo de dispositivo /dev/audio. Essa codificação e interface se tornaram um padrão de fato para o som do Unix.
Novo formato
Todos os campos são armazenados no formato big-endian, incluindo os dados de amostra.
| Página não encontrada | campo de campo | Descrição |
|---|---|---|
| 0 | Número de magia | O valor 0x2e736e64 (quatro caracteres ASCII ".snd) |
| 1 | Transferência de dados | O deslocamento para os dados em bytes. (Na versão mais antiga do Sol, isso teve que ser um múltiplo de 8.) O número mínimo válido é 28 (decimal), uma vez que este é o comprimento do cabeçalho (seis palavras de 32 bits) mais um tamanho mínimo de anotação (4 bytes, outra palavra de 32 bits). |
| 2 | tamanho de dados | Tamanho de dados em bytes, não incluindo o cabeçalho. Se desconhecido, o valor 0xffffffff deve ser usado. |
| 3 | Codificação | Formato de codificação de dados:
Os valores 0 a 255 devem ser atribuídos por uma autoridade de formato de arquivo (era NeXT, agora Oracle). Outros valores podem ser usados para formatos personalizados. |
| 4 | Taxa de amostragem | O número de amostras/segundo, por exemplo, 8000, 11025, 22050, 44100 e 48000. NeXT pode usar 8013. |
| 5 | Canais | O número de canais interligados, por exemplo, 1 para mono, 2 para estéreo; mais canais possíveis, mas podem não ser suportados por todos os leitores. |
| 6 | – | Annotação ou descrição opcional string, NULL-terminou. Um mínimo de 4 bytes deve ser armazenado mesmo que não seja usado.
Na versão mais antiga do Sol, seu comprimento teve de ser um múltiplo não zero de 8 bytes. Em algumas implementações mais antigas, a cadeia de caracteres não é devidamente marcada por NULL, mas o deslocamento permanece confiável. |
O tipo de codificação depende do valor do campo "encodificação" (palavra 3 do cabeçalho). Formatos 2 a 7 são PCM linear não compactado, portanto tecnicamente sem perdas (embora não necessariamente livre de erro de quantificação, especialmente em forma de 8 bits). Formatos 1 e 27 são μ-law e A-law, respectivamente, ambas companding representações logarítmicas de PCM, e arguably lossy como eles embalam o que de outra forma seria quase 16 bits de alcance dinâmico em 8 bits de dados codificados, mesmo que isso seja alcançado por uma resposta dinâmica alterada e nenhum dado é realmente "afastado". Formatos 23 a 26 são ADPCM, que é uma forma precoce de compressão com perda, geralmente, mas nem sempre com 4 bits de dados codificados por amostra de áudio (para eficiência 4:1 com entrada de 16 bits, ou 2:1 com 8 bits; equivalente a codificar MP3 de qualidade de CD em uma taxa de 352kbit usando um codificador de baixa qualidade). Vários dos outros (número 8 a 22) são comandos ou dados DSP, projetados para serem processados pelo software NeXT Music Kit.
Nota: Os formatos PCM são codificados como dados assinados (ao contrário de não assinados).
O formato atual suporta apenas um único segmento de dados de áudio por arquivo. O campo de anotação de comprimento variável é atualmente ignorado pela maioria dos aplicativos de áudio.