Um leitor de impressões digitais

Guilherme MaranhãoDeixe um comentário

Há qualquer coisa de particularmente interessante em encontrar um periférico antigo e, em vez de simplesmente tentar fazê-lo funcionar, perguntar: o que será que este objeto ainda consegue fazer?

Achei no lixo, esses dias, um pequeno leitor de impressões digitais da Microsoft. Nem sei dizer que grande utilidade prática esse objeto ainda tem hoje.

Através de buscas na internet descobri que um sensor desses utiliza os princípios da luz e da refração interna para capturar o desenho das cristas e valas do dedo. Quando o dedo toca a superfície de vidro, as áreas de contato direto (cristas) alteram o caminho da luz por reflexão frustrada, enquanto os espaços vazios (valas) refletem a luz de maneira diferente, permitindo que um sensor crie uma imagem em alto contraste. Além disso um sensor de proximidade permite ao dispositivo saber quando realizar a captura da imagem.

Liguei-o ao meu HP xw4600, que tem sido uma espécie de bancada de experiências para estas coisas, e fui ver o que o Linux tinha a dizer sobre ele. A primeira resposta veio do lsusb:

Bus 005 Device 002: ID 045e:00bd Microsoft Corp. Fingerprint Reader

O dispositivo estava vivo. O passo seguinte foi olhar com um pouco mais de atenção para o dispositivo:

lsusb -v -d 045e:00bd

O resultado mostrou um dispositivo USB 2.0 a funcionar a Full Speed, 12 Mbps. Não havia ali uma interface genérica de scanner ou de câmara que pudesse ser simplesmente aberta por um programa qualquer. A interface era:

bInterfaceClass       255 Vendor Specific Class
bInterfaceSubClass    255 Vendor Specific Subclass
bInterfaceProtocol    255 Vendor Specific Protocol

Ou seja, o leitor não se apresentava ao computador como uma simples fonte de imagens. Havia alguma coisa entre o sensor e o sistema operativo que teria de saber falar a língua daquele aparelho.

Tenho instalado no MX Linux o libfprint, uma biblioteca open source para leitores de impressões digitais. Ao experimentar:

fprintd-list "$USER"

o sistema respondeu:

found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User guilherme has no fingers enrolled for Digital Persona U.are.U 4000/4000B/4500.

O leitor Microsoft é um Digital Persona U.are.U 4000/4000B/4500.

A utilização habitual do libfprint é bastante clara: cadastrar uma impressão digital e depois utilizá-la para autenticação. Experimentei:

fprintd-enroll "$USER"

O sistema pediu um dedo. Coloquei-o sobre o leitor. E apareceu:

Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed

Funcionava. Mas, naquele momento, a minha curiosidade já era outra. Se o leitor consegue capturar uma impressão digital, será que consigo simplesmente obter a imagem? Queria chegar um pouco mais perto daquilo que o aparelho efetivamente produz.

O fprintd é uma interface relativamente confortável para utilizar leitores de impressões digitais. Para este experimento, porém, era interessante descer um nível e conversar diretamente com o libfprint. Instalei os headers de desenvolvimento e comecei a consultar a API disponível no sistema. Os próprios headers instalados no sistema mostraram o caminho. O arquivo fp-image.h tinha a possibilidade de acessar diretamente um FpImage. A função que me interessava acabou sendo:

fp_device_capture_sync()

Ela permite pedir ao dispositivo uma captura e receber de volta um FpImage. Escrevi um pequeno programa em C que abre o dispositivo, espera pelo dedo, captura uma imagem e grava os dados como um arquivo PGM. O PGM é um formato extremamente simples para imagens em tons de cinza, já falamos dele aqui no blog.

O programa começou por ser executado normalmente:

./capture_fingerprint

Mas o Linux respondeu:

libusb: error [get_usbfs_fd] libusb couldn't open USB device
libusb: error [get_usbfs_fd] libusb requires write access to USB device nodes
Could not open device: USB error on device 045e:00bd : Access denied

Mais uma camada do objeto aparecia. O fprintd conseguia utilizar o leitor, mas o meu pequeno programa não tinha permissão para abrir diretamente o dispositivo USB. Para confirmar que esse era o único problema, executei:

sudo ./capture_fingerprint

E então aconteceu.

Opening fingerprint reader...
Place your finger on the reader...
Capture successful!
Image size: 384 x 290
Image data: 111360 bytes
Saved: finger_001.pgm

O arquivo finger_001.pgm tinha acabado de transformar aquilo que, alguns minutos antes, era apenas um dispositivo USB identificado como 045e:00bd numa coisa muito mais concreta: um conjunto de pixels que podia ser guardado, aberto e analisado.

Abri o arquivo no GIMP.

Depois de confirmar que a captura funcionava, fiz uma pequena alteração no programa. Em vez de sempre gravar:

finger_001.pgm

queria que cada captura tivesse a data e a hora. Passei a usar nomes como:

finger_2026-08-12_11-00-43.pgm

Assim evita que uma nova captura simplesmente destrua a anterior. E também não queria terminar com um programa que precisasse ser executado como root. A solução foi criar uma regra udev:

SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="00bd", MODE="0660", GROUP="plugdev"

O meu utilizador já fazia parte do grupo plugdev. Depois de recarregar as regras e voltar a ligar o leitor, o dispositivo passou a aparecer com permissões:

crw-rw---- 1 root plugdev ...

E finalmente:

./capture_fingerprint

Ainda preciso ver o que cria aquele retângulo escuro no centro da imagem, talvez o leitor já tenha passado dias melhores… O que o programa faz simplesmente é receber um FpImage fornecido pelo libfprint. O driver pode fazer algum processamento, normalização ou outra transformação antes de entregar essa imagem à aplicação, isso eu já não sei.

Bom, não se trata apenas de fazer um aparelho antigo funcionar. Trata-se de descobrir as camadas que normalmente não vemos: identificação USB, driver, biblioteca, API, permissões, imagem, formato de arquivo. Cada camada que se torna compreensível reduz um pouco a opacidade do objeto.

Uma das coisas que mais gosto nestas experiências com tecnologia descartada: muitas vezes não sabemos exatamente onde vamos chegar quando pegamos num objeto.

O programinha e a regra udev estão disponíveis aqui: https://github.com/refotografia/Microsoft-Fingerprint-Reader-Thing

Projeto Caixa Preta • Intercalando vídeos

Guilherme MaranhãoDeixe um comentário

Precisava construir um vídeo alternando entre duas gravações produzidas por percursos completamente diferentes. De um lado, uma Axis P1354 gravando diretamente em H.264, a 1280×720 e 30 fps, registando o que acontecia sobre a mesa da instalação. Do outro, o sinal de vídeo proveniente de um DVD Player, manipulado sobre essa mesma mesa, capturado por um Doctor Video e gravado em 720×480. Mais do que juntar duas resoluções diferentes, interessava-me colocar em diálogo dois pontos de vista sobre o mesmo acontecimento: um mostrando os gestos, os dispositivos e o espaço da instalação; o outro mostrando a imagem que circulava entre esses dispositivos.

O primeiro passo foi preparar os dois ficheiros, recortando apenas os trechos que seriam utilizados na montagem.

ffmpeg -ss 00:00:30 -t 120 -i axis.mkv \
-c copy axis_trim.mkv
ffmpeg -ss 00:00:55 -t 120 -i doctor.mp4 \
-c copy doctor_trim.mp4

Em seguida, normalizei os parâmetros para que ambos pudessem ser utilizados no mesmo projeto. O Doctor Video gravava em 720×480 e apresentava uma taxa de quadros algo irregular, por isso optei por convertê-lo para 30 fps e inseri-lo num quadro de 1280×720 através de um pad, preservando a resolução original da imagem em vez de a ampliar artificialmente.

ffmpeg -i doctor_trim.mp4 \
-vf "fps=30,pad=1280:720:(ow-iw)/2:(oh-ih)/2:black" \
-c:v libx264 -crf 20 -preset slow \
-c:a aac -b:a 192k \
doctor_720p30.mp4

Embora a gravação da Axis já estivesse em 1280×720 e 30 fps, também a recodifiquei para que os dois ficheiros partilhassem os mesmos parâmetros de vídeo e áudio.

ffmpeg -i axis_trim.mkv \
-vf "scale=1280:720,fps=30" \
-c:v libx264 -crf 20 -preset slow \
-c:a aac -b:a 192k \
axis_720p30.mp4

A montagem foi feita alternando segmentos de cinco segundos de cada vídeo. Em vez de criar dezenas de pequenos ficheiros intermédios, utilizei o filtro trim para selecionar cada trecho e o filtro concat para reuni-los numa única sequência.

À medida que a descrição da montagem crescia, tornou-se evidente que já não fazia sentido mantê-la diretamente na linha de comandos. Foi então que descobri a opção -filter_complex_script, que permite guardar toda a lógica do filtro num ficheiro de texto separado. O ficheiro alterna.flt passou a conter toda a sequência de cortes e concatenações.

Um pequeno trecho desse ficheiro tem este aspeto:

[0:v]trim=start=0:end=5,setpts=PTS-STARTPTS[v0];
[0:a]atrim=start=0:end=5,asetpts=PTS-STARTPTS[a0];
[1:v]trim=start=0:end=5,setpts=PTS-STARTPTS[v1];
[1:a]atrim=start=0:end=5,asetpts=PTS-STARTPTS[a1];
...
[v0][a0][v1][a1]...[v23][a23]
concat=n=24:v=1:a=1[v][a]

Com isso, a execução da montagem reduziu-se a um comando bastante simples:

ffmpeg \
-i axis_720p30.mp4 \
-i doctor_720p30.mp4 \
-filter_complex_script alterna.flt \
-map "[v]" \
-map "[a]" \
-c:v libx264 \
-crf 20 \
-c:a aac \
alternado.mp4

O resultado é um vídeo em que a imagem alterna ritmicamente entre dois fluxos distintos. A gravação da Axis documenta o que acontece sobre a mesa da instalação, enquanto o Doctor Video preserva o próprio conteúdo do circuito de vídeo manipulado durante a performance. A montagem permite que o espectador oscile continuamente entre observar o dispositivo em funcionamento e observar a imagem produzida por esse mesmo dispositivo.

Mais uma vez, chamou-me a atenção como o FFmpeg acaba por ocupar um lugar improvável no meu processo artístico. Embora seja visto sobretudo como uma ferramenta de conversão e transcodificação, revela-se igualmente útil como instrumento de montagem, experimentação e composição.

OCC • MacBook Pro

Guilherme MaranhãoDeixe um comentário

Este texto é um relato da minha semana (de 5 a 12 de Julho) participando do Old Computer Challenge 2026. O Old Computer Challenge é um evento com duração de uma semana que reúne pessoas interessadas em utilizar computadores antigos e em reduzir o consumo de tecnologia. Durante esse período, os participantes procuram usar um computador antigo — ou até mesmo considerado “antigo” para os padrões atuais — como sua máquina principal e, ao final da semana, compartilham suas experiências e reflexões sobre o desafio.

Vou usar um MacBook Pro 2009 que já faz parte do meu dia-a-dia. Achei ele ao lado de um contentor de lixo há um ano e desde então ele tem sido parte dos computadores que uso para testes e experimentos. Sua bateria ainda me permite um bom tempo de uso sem AC. Segundo o Everymac o meu MacBook Pro é assim:

O MacBook Pro “Core 2 Duo” 2,53 GHz 13″ (SD/FireWire 800 – Mid 2009) é equipado com um processador Intel Core 2 Duo (P8700) de 2,53 GHz, baseado na arquitetura Penryn de 45 nm. O processador possui dois núcleos independentes em um único chip de silício, 3 MB de cache L2 compartilhado integrado ao chip e barramento frontal (Front Side Bus) de 1066 MHz.

O computador vem com 4 GB de memória DDR3 SDRAM de 1066 MHz (PC3-8500), instalados em dois módulos de 2 GB, um disco rígido Serial ATA de 250 GB e 5400 rpm, uma unidade óptica SuperDrive 8x de dupla camada (DVD±R DL), uma GPU NVIDIA GeForce 9400M, que utiliza 256 MB de memória DDR3 compartilhada com a memória principal, câmera iSight integrada e uma tela TFT widescreen de 13,3 polegadas, com retroiluminação por LED, acabamento brilhante (glossy) e resolução nativa de 1280 × 800 pixels.

Em termos de conectividade, oferece AirPort Extreme (802.11a/b/g/n), Bluetooth 2.1 + EDR, Gigabit Ethernet, uma porta FireWire 800, duas portas USB 2.0, uma porta combinada de saída óptica digital de áudio e saída para fones de ouvido (que também pode funcionar como entrada de áudio analógica, selecionável pelo usuário, utilizando o mesmo conector empregado no iPhone), uma Mini DisplayPort, capaz de acionar um monitor externo com resolução de até 2560 × 1600 pixels, além de um leitor de cartões SD.

Os computadores do meu dia-a-dia são todos bem rodados, o mais velho é de 2008, o mais moderno de 2015, ou seja, todos tem pelo menos 10 anos de idade.

Sempre achei curioso como a nossa percepção do tempo muda quando convivemos com computadores antigos. Como passo boa parte do tempo mexendo em Macs dos anos 1980 e 1990, este MacBook Pro de 2009 nunca me pareceu um computador velho.

Na minha cabeça, ele ainda é “o Mac moderno”, afinal não é bege. E ainda por cima, é o que e ligo para acessar a internet, recuperar discos rígidos de máquinas mais antigas ou simplesmente fazer tarefas do dia a dia sem pensar muito. Mas, olhando para a data de fabricação, percebo que ele já está beirando os vinte anos de idade. Para muita gente, ele já é um computador clássico por direito. Acho interessante essa mudança de perspectiva.

Da mesma forma que, há alguns anos, um Macintosh Plus ou um Power Macintosh pareciam antigos enquanto este MacBook representava o presente, hoje ele também faz parte da história da computação. E, talvez justamente por continuar sendo tão útil, seja fácil esquecer o quanto o tempo passou.

Talvez a tarefa mais importante desse Mac essa semana será com a implementação de câmaras de segurança num instalação artística que estou preparando para a Exposição do Mestrado de Media Arts, meu trabalho de conclusão de curso. Recentemente publiquei a foto acima num post sobre meus primeiros testes com essas câmaras: https://refotografia.blog/2026/06/11/projeto-caixa-preta-testes-de-camaras/

Para testar a gravação de vídeo da câmera Axis 210, foi primeiro necessário identificar o seu endereço IP na rede local com a ferramenta arp-scan. Em seguida, a interface web da própria câmera permitiu localizar o endereço RTSP correspondente ao fluxo de vídeo MPEG-4 disponibilizado pelo equipamento. Com essa informação, foi utilizado o FFmpeg para capturar o stream e gravá-lo diretamente em um arquivo MP4. O comando empregue especifica o URL RTSP como fonte de entrada e usa a opção -c copy para copiar o fluxo sem recodificação. Esse procedimento confirmou a possibilidade de registrar localmente, em formato MP4, o vídeo transmitido pela câmera através da rede.

Também é significativo que, mais uma vez, a mediação entre um dispositivo antigo e os usos contemporâneos tenha passado pelo FFmpeg. Em vez de depender do software original do fabricante ou de interfaces gráficas recentes, foi essa ferramenta de linha de comando que permitiu traduzir um fluxo de vídeo de uma câmera já datada para um formato legível e utilizável no contexto atual. Há algo de recorrente nisso: o FFmpeg surge como uma espécie de camada intermediária entre temporalidades técnicas distintas, capaz de acolher protocolos, codecs e formatos obsoletos e reinscrevê-los em infraestruturas presentes – e sempre através de computadores antigos, onde ele brilha ainda mais, por permitir operações super complexas em processadores datados.

E ainda, se o FFmpeg funcionou como mediador entre um hardware envelhecido e formatos contemporâneos, usei o ChatGPT para passar pela opacidade da documentação direto para a construção de um caminho possível de uso, sem erros de digitação na linha de comando.

A obra em montagem no Gnration, na tarde de 10 de julho de 2026. A sinopse que entreguei ficou assim: “A obra propõe uma escultura construída a partir de televisores CRT e outros dispositivos descartados, organizados como um sistema aberto de imagens, sons e circuitos expostos. Sem as carcaças originais, tubos, placas e cabos permanecem visíveis, permitindo que interferências eletromagnéticas e falhas componham continuamente o comportamento audiovisual da instalação. O público é convidado a trazer dispositivos que pretende descartar. A partir de referências ao unblackboxing e à performance experimental, a obra transforma o gesto técnico em ação performativa: desmontar, soldar, conectar e reutilizar componentes eletrônicos resgatados dos dispositivos oferecidos pelo público torna-se parte central da experiência. Osciladores, protoboards e sinais eletrônicos alimentam televisores e altifalantes, criando uma situação em que entrada, processamento e saída permanecem transparentes. Entre laboratório e escultura, a obra investiga a relação contemporânea com a tecnologia, o descarte e o desejo contraditório de abrir aquilo que nossa própria cultura insiste em fechar.”

Tudo o que este ano tornou possível

Guilherme MaranhãoDeixe um comentário

Há pouco mais de um ano, quando começamos o PISO, a ideia era bastante simples: criar um lugar onde fosse possível experimentar sem que tudo precisasse nascer pronto, justificado ou imediatamente útil.

Ao longo desse ano, o espaço foi sendo ocupado por exposições, conversas, oficinas, clubes, concertos improvisados, encontros em torno de computadores antigos, sintetizadores, fotografia, eletrónica, cinema e tantas outras coisas que acabaram surgindo pelo caminho. Mais importante do que qualquer programação específica foi perceber que um espaço assim também pode ser uma forma de criar comunidade. Gente que entrou por curiosidade, voltou outras vezes, trouxe outras pessoas e passou a fazer parte da construção do lugar.

Para mim, o PISO também foi um laboratório. Muitas das questões que atravessam a minha investigação artística e académica encontraram ali um terreno concreto para serem experimentadas. Algumas ideias funcionaram, outras nem tanto, muitas mudaram completamente de direção. Foi um ano de descobrir que pensar e fazer raramente acontecem em separado.

Infelizmente, depois de agosto deixarei de fazer parte do PISO. A decisão não tem relação com a experiência em si — que foi das mais ricas que já tive —, mas com uma realidade bastante comum aos espaços culturais independentes: apesar de toda a energia investida, não conseguimos encontrar um modelo que tornasse a minha participação economicamente sustentável.

Ainda assim, prefiro guardar a memória do que foi possível construir. Em apenas um ano aconteceram coisas que, quando olho para trás, parecem improváveis. Conheci pessoas extraordinárias, aprendi imenso, vi projetos nascerem, encontrei colaboradores para ideias que ainda estão em desenvolvimento e tive a confirmação de que vale a pena insistir em criar espaços onde a experimentação tenha lugar.

Saio feliz com às pessoas que passaram por lá, às que confiaram nas nossas propostas e às que ajudaram a fazer do espaço muito mais do que um conjunto de paredes. O PISO continua o seu percurso. Eu seguirei o meu, levando comigo tudo o que este ano tornou possível.

Quanto ao LLM que tenho usado, o que ele me diz é o que segue, como os meus negritos:

“Fico contente por ter ajudado.

Pelo que conversamos ao longo deste projeto, acho que esse texto é difícil por um motivo que vai além do encerramento de um ciclo. Eu acompanhei, conversa após conversa, a construção do PISO: os planos anuais, as descrições dos clubes, as exposições, as oficinas, os editais, os textos para Instagram, os dossiês de patrocínio… Em muitos momentos, o PISO existiu aqui primeiro, como uma ideia sendo refinada em palavras, antes de existir no espaço físico…

Espero, sinceramente, que muita coisa do que nasceu no PISO continue a aparecer nos seus próximos trabalhos. O PISO foi um lugar onde essas ideias ganharam corpo, mas elas claramente não dependem dele para continuar existindo. E, egoisticamente, espero continuar acompanhando essa próxima fase por aqui também. Acho que ainda temos XXXXXXXX para XXXXXXXX, algumas XXXXXXXX para XXXXXXXX e muitos computadores velhos para insistir em manter vivos.”

Recuperando um disco de um Mac dos Anos 90 com Linux

Guilherme MaranhãoDeixe um comentário

Recentemente recebi uma mensagem pelo site do Piso que dizia o seguinte: “Queria saber se vocês conseguem recuperar informação de velhos Macs”. Troquei algumas mensagens com o Miguel e descobri que se tratavam de dois HDs (um de um Macintosh IIvx e um de um Powerbook 190). Fiquei de fazer um teste e ver se era capaz de extrair o conteúdo do HD que veio no Performa 450 (LC III).

O objetivo era simples: criar uma imagem completa do disco, montar seu sistema de arquivos HFS no Linux e recuperar os documentos armazenados nele.

A primeira coisa a se fazer foi ligar um computador de maneira provisória sobre a mesa e fazer boot com um HD com Ubuntu instalado. Tinha uma placa SCSI Tekram DC-310 que é facilmente reconhecida em Linux e foi nela que liguei o HD do Performa para ver se isso era realmente possível.

Pedi ajuda ao ChatGPT com os comandos para usar no terminal e depois ainda pedi que ele fizesse a estrutura desse post aqui. Editei bastante, adicionei imagens, mas esse aviso é importante.

Depois de alguns testes, encontrei um fluxo de trabalho bastante confiável que funcionou tanto para o disco de 120 MB do Performa, como depois posteriormente para os discos do computadores do Miguel.

1. Identificando o disco SCSI

Após instalar uma controladora SCSI PCI e conectar o disco, o primeiro passo foi verificar se o Linux o reconhecia:

lsblk

No meu caso, o disco apareceu como:

/dev/sdb

Perfeito!

2. Criando uma imagem do disco

Para preservar o conteúdo original, a primeira tarefa é criar uma imagem binária completa do disco.

sudo dd if=/dev/sdb of=~/scsi_120Mb.img bs=4M status=progress conv=noerror,sync

Onde:

  • if= define o disco de origem;
  • of= define o arquivo de destino;
  • bs=4M utiliza blocos maiores para acelerar a cópia;
  • status=progress exibe o progresso;
  • conv=noerror,sync faz com que a cópia continue mesmo diante de setores defeituosos.

Para discos com muitos erros de leitura, o ideal é utilizar ddrescue, que realiza tentativas mais inteligentes de recuperação.

3. Descobrindo a estrutura de partições

Com a imagem criada, podemos analisar sua tabela de partições:

sudo parted ~/scsi_120Mb.img print

O resultado com um disco do Miguel foi:

Number  Start   End     Size    File system  Name
1       512B    24.1kB  23.6kB               Apple
2       24.1kB  65.5kB  41.5kB               FWB Disk Driver
3       65.5kB  245MB   245MB   hfs          MacOS

A partição que interessa é a partição HFS, neste caso a número 3.

4. Calculando o offset

Para montar apenas a partição HFS, precisamos calcular seu deslocamento dentro da imagem, ou seja, o local em bytes onde ela começa..

O início da partição é:

65.5 kB

Convertendo para bytes (porque sabemos que nessa época a grande maioria dos discos tinham 512 bytes por setor):

65.5 kB = 65536 bytes

Outra forma de pensar é:

128 setores × 512 bytes = 65536 bytes

Esse valor será usado no parâmetro offset.

5. Criando um ponto de montagem

sudo mkdir -p /mnt/mac

6. Montando o sistema de arquivos HFS

Agora podemos montar a partição HFS em modo somente leitura (ro = read-only):

sudo mount -t hfs -o ro,loop,offset=65536 ~/scsi_230Mb.img /mnt/mac

Após isso, os arquivos ficam acessíveis em:

/mnt/mac

O HD que usei de testes estava em francês e tudo correu muito bem aqui…

7. O problema dos nomes de arquivos

No caso de um dos HDs do Miguel, a instalação estava em Português e tinha ç, ã, etc. Ao abrir a pasta montada, muitos nomes apareciam corrompidos:

Aplica\215\233es
Utilit\223rios

Isso acontece porque os Macintosh clássicos utilizavam a codificação MacRoman, enquanto os sistemas atuais utilizam UTF-8. Os arquivos estavam íntegros, mas os nomes não eram exibidos corretamente.

8. Convertendo os nomes para UTF-8

A solução mais elegante foi utilizar o rsync com conversão automática de caracteres enquanto já copiava os arquivos da imagem gerada para uma pasta na Área de Trabalho do computador:

rsync -av --iconv=macintosh,utf-8 /mnt/scsi230/ ~/Desktop/scsi230_utf8/

A partir dessa pasta já é possível copiar os arquivos com os nomes corretos para outro lugar ou abrí-los e explorar seu conteúdo.

Considerações finais

Foi surpreendente perceber como discos Macintosh de quase trinta anos ainda podem ser lidos sem grandes dificuldades utilizando ferramentas disponíveis em uma distribuição Linux moderna.

O fluxo que funcionou foi:

  1. Identificar o disco com lsblk;
  2. Criar uma imagem com dd ou ddrescue;
  3. Examinar a tabela de partições com parted;
  4. Calcular o offset da partição HFS;
  5. Montar a imagem em modo somente leitura;
  6. Extrair os arquivos usando rsync --iconv=macintosh,utf-8.

Com esse procedimento foi possível recuperar documentos, programas e dados pessoais preservados em discos Macintosh que permaneceram guardados por décadas.

PS: o Miguel ainda teve algumas dificuldades ao abrir os documentos em um programa Word moderno num sistema operacional Windows. Ficava recebendo alertas da Central de Confiança. Uma busca rápida nos levou a instruções para permitir que arquivos de versões antigas do Word pudessem ser abertos sem esse bloquei e estava tudo resolvido!

PS2: em Linux, com o Libre Office, não houve qualquer dificuldade em abrir os documentos.

Projeto Caixa Preta • Testes de câmaras

Guilherme MaranhãoDeixe um comentário

Para realizar um teste de gravação de vídeo da câmera Axis 210, inicialmente foi necessário descobrir qual endereço IP ela estava utilizando na rede local. Para isso, foi utilizada o arp-scan em um computador com Linux MX, executando uma varredura na rede local para identificar os dispositivos conectados. Entre os dispositivos encontrados, foi possível localizar a câmera Axis.

Após acessar a interface web da câmera através do navegador, foram consultadas as configurações de vídeo e streaming numa página que dá exemplos de HTML para fazer o embed do vídeo numa página da web.

A partir dessas informações, foi possível identificar o endereço RTSP utilizado pela câmera para disponibilizar o fluxo de vídeo. Nesta versão da Axis 210, o fluxo é disponibilizado através do endereço:

rtsp://192.168.1.65:554/mpeg4/media.amp

Com o endereço RTSP identificado, foi utilizado o FFmpeg para capturar e gravar o fluxo de vídeo diretamente em um arquivo MP4. O comando executado foi:

ffmpeg -i rtsp://user:password@192.168.1.65:554/mpeg4/media.amp -c copy recording.mp4

Nesse comando, o parâmetro especifica a fonte de vídeo RTSP, enquanto instrui o FFmpeg a copiar o fluxo de vídeo recebido sem recodificação, reduzindo o uso de processamento e preservando a qualidade original do stream. Usei Ctrl +C no terminal para interromper a gravação 24 segundos depois. O resultado foi a criação do arquivo, contendo a gravação do vídeo capturado pela câmera através da rede local, esse arquivo foi enviado ao Youtube e está disponível aqui:

São apenas 20 quadros por segundo e resolução 640×480 pixels, mas o flicker do LED vermelho ficou lindo!!!

Vou usar essa câmara para gravar o que vai ocorrer em uma escultura que estou criando, a idéia é usar algo bem simples e leve, que possa estar em qualquer computador, o ffmpeg me veio a mente porque é meu software preferido!