Eu tenho esses arquivos .m4a para os quais ffprobe(no Debian 12.1) relatórios:
Stream #0:1[0x2](eng): Data: bin_data (text / 0x74786574), 0 kb/s
Metadata:
handler_name : SubtitleHandler
Unsupported codec with id 98314 for input stream 1
São letras de músicas e, em caso afirmativo, como posso extraí-las como texto simples?
Estou tentando identificar arquivos com taxa de bits alta/baixa em minha coleção de áudio usando um script de shell. Fazer file test.mp3é muito rápido:
$time file test.mp3
test.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
real 0m0.027s
No entanto, filenão mostra a taxa de bits dos arquivos .m4a:
$time file test.m4a
test.m4a: ISO Media, Apple iTunes ALAC/AAC-LC (.M4A) Audio
real 0m0.056s
Tentei usar exiftoole ffprobe, mas eles parecem ser pelo menos 10 vezes mais lentos:
$time exiftool test.m4a
Avg Bitrate : 131 kbps
real 0m0.532s
$time ffprobe test.m4a
Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 130 kb/s (default)
real 0m0.621s
São apenas cerca de 100 arquivos/minuto, o que é bastante lento. Existe uma maneira mais rápida de encontrar a taxa de bits de arquivos m4a? Entendo que isso ffprobeverifica os dados do stream em vez das tags, por isso é mais preciso que o file. Aceito um valor de taxa de bits menos preciso, desde que seja rápido.
Recentemente, percebi que fileno Debian Bullseye não reconhecerá alguns dos formatos de arquivo com os quais estou lidando, me dizendo que são apenas arquivos ZIP:
user@host:~ $ file file.docx # Correct, not a regular ZIP file
file.docx: Microsoft Word 2007+
user@host:~ $ file file.key # Incorrect, also not a regular ZIP file
file.key: Zip archive data, at least v2.0 to extract
No entanto, se eu olhar para os arquivos com pcmanfm, vejo que os tipos de arquivo são reconhecidos corretamente:
"file.docx" (50.5kB) Word 2007 document
"file.key" (10.4MB) Apple Keynote 5 presentation
É possível dizer filepara usar o mesmo arquivo mágico que pcmanfmusa ou de alguma forma atualizar o padrão /etc/magicpara filereconhecer os formatos de documentos populares?
A página man para setlocaleparece dizer que o código do idioma e o nome da codificação de caracteres são suficientes para definir a localidade apropriada:
Um nome de localidade geralmente tem o formato language[_territory][.codeset][@modifier], em que language é um código de idioma ISO 639, território é um código de país ISO 3166 e codeset é um conjunto de caracteres ou identificador de codificação como ISO- 8859-1 ou UTF-8.
No entanto, um teste rápido mostra que apenas a parte "modificadora" de um nome de localidade é opcional:
void tryLocale(const char * locid)
{
char * result = std::setlocale(LC_CTYPE, locid);
std::cout << locid << " = " << (result ? result : "fail") << std::endl;
}
int main()
{
tryLocale("de"); // de = fail
tryLocale("de_DE"); // de_DE = fail
tryLocale("de_DE.CP1252"); // de_DE.CP1252 = de_DE.CP1252
tryLocale("de.CP1252"); // de.CP1252 = fail
tryLocale(".CP1252"); // .CP1252 = fail
}
Meu problema é que eu só sei o nome da codificação desejada (por exemplo ISO-8859-1, ) e posso criar o código do idioma (por exemplo, en). Não tenho ideia de como encontrar um nome de país apropriado (por exemplo US, ), e não estou interessado em um país de qualquer maneira: só quero que funções como tolowerno meu aplicativo usem a página de código correta.
Acabei de notar algo peculiar sobre como sudolida com o .Xauthorityarquivo:
sudo xauth add $(xauth list | tail -1)
user@server: sudo xauth info
Authority file: /root/.xauthYZ21Nt
File new: no
File locked: no
Number of entries: 1
Changes honored: yes
Changes made: no
Current input: (argv):1
user@server: sudo xauth info
Authority file: /root/.xauth3BFy5d
File new: no
File locked: no
Number of entries: 1
Changes honored: yes
Changes made: no
Current input: (argv):1
user@server: sudo xauth list
server/unix:10 MIT-MAGIC-COOKIE-1 c922ab48defdf43b1092dffb86c06eed
user@server: sudo ls -la /root | grep auth
-rw-r--r-- 1 root root 0 Nov 9 14:40 .Xauthority
-rw------- 1 root root 57 Nov 9 15:23 .xauthsrxzxl
user@server: pkexec xauth info
Authority file: /root/.Xauthority
File new: no
File locked: no
Number of entries: 0
Changes honored: yes
Changes made: no
Current input: (argv):1
Portanto, $XAUTHORITYvalue é diferente em cada new sudo, e aponta para um arquivo temporário que desaparece quando sudo sai. Por causa disso, o último comando (que usa pkexecem vez de sudoe espera que esteja em /root/.Xauthority) não consegue ver o cookie. Por exemplo, sudo geditfunciona bem, mas pkexec env DISPLAY=$DISPLAY geditfalha.
Por que isso é feito de maneira tão complicada, onde os dados são armazenados e, mais importante, como posso acessar .Xauthorityos dados com pkexec?