Griffonage-Dot-Com

Explorações de Patrick Feaster na mídia histórica

Casa Sobre

Novo software para reproduzir imagens de

ondas sonoras
Patrick Feaster / 20 de novembro de 2016

Depois de anos tentando fazer com que o software existente fizesse coisas que nunca
pretendia fazer, finalmente escrevi um código próprio para converter imagens de ondas
sonoras em áudio reproduzível. Ele não tem interfaces amigáveis, mas é relativamente fácil
de usar e é grátis (como na cerveja grátis, não no cachorro grátis), então o preço é justo.

Digamos que você tenha uma imagem digitalizada de uma forma de onda de áudio - um
gráfico da amplitude das vibrações sonoras em função do tempo. Talvez seja um fono-
logógrafo da década de 1850 ou 1860: um registro de som traçado em fuligem em uma
folha de papel em movimento para análise visual em um momento em que a reprodução
ainda não estava na mesa. Ou talvez seja uma impressão de tinta em papel feita de um
disco de gramofone algumas décadas depois (convertida, neste caso, de uma espiral em
linhas paralelas por uma transformação de coordenadas polar para retangular). Ou talvez
seja apenas uma linha aleatória que você quer tratar como uma forma de onda de áudio
para descobrir o que acontece. Quem sou eu para julgar?

A questão é como converter essa imagem em um arquivo de áudio reproduzível para que
possamos ouvi-la.
Eu já descrevi anteriormente um método tortuoso de fazer isso aqui e aqui , assim como no
meu livro Pictures of Sound . Esse método funciona, mas um ponto levantado por um leitor
é bem aceito:

“ Parece que você usou um processo extraordinariamente longo e complicado

para gerar um som quase inaudível. Não seria mais fácil escrever algum
software para fazer isso e produzir maior fidelidade?

A tecnica

No passado, eu já contou com Andrew Jaremko ImageToSound , um pedaço de freeware

projetado para converter qualquer 24-bit BMP em um arquivo WAV de 8 bits, como se fosse
uma imagem de uma trilha sonora de filme óptico. Em trilhas sonoras de filmes ópticos, a
modulação do sinal de áudio está vinculada à quantidade de luz que passa por uma faixa
translúcida que varia em opacidade (“densidade variável”, abaixo à esquerda) ou largura
(“área variável”, abaixo à direita, com agradecimentos para Iainf para as ilustrações).

ImageToSound converte as somas de luminância de pixel em cada coluna sucessiva em

um arquivo de imagem de origem em sucessivas amostras de áudio em um arquivo WAV
de destino. À primeira vista, isso pode não parecer aplicável a fontes de reprodução, como
os fonoautogramas. Mas, oito anos atrás, percebi que podia converter uma linha ondulada
em uma faixa brilhante de largura variável preenchendo a área acima ou abaixo com
branco usando uma ferramenta comum de Photoshop, e que o ImageToSound poderia ser
usado para convertê-la em áudio. . Mais recentemente, ocorreu-me que poderíamos
converter esse resultado em uma faixa de brilho variável, reduzindo-o a um pixel de altura
e, em seguida, (opcionalmente) expandindo-o - não é particularmente útil, imagino, mas o
ImageToSound pode manipular também nessa forma.

Este procedimento tem suas desvantagens. Ele pode exigir muita edição manual demorada
para limpar a área em ambos os lados do traçado e conectar quaisquer quebras nele, de
modo que a ferramenta paintbucket não “transborde” para o outro lado. Enquanto isso, o
software ImageToSound tem algumas peculiaridades e limitações infelizes e está se
tornando cada vez mais difícil de executar - ainda posso executá-lo com êxito no meu
laptop atual do Windows 10 no modo de compatibilidade do Windows 98, mas outros me
disseram que não podem funcionar . Infelizmente, não houve alternativas convenientes.
AEO-Lighté projetado para converter imagens digitais de trilhas sonoras de filmes ópticos
em áudio sobre praticamente o mesmo princípio do ImageToSound, mas está configurado
para assumir que haverá quadros de imagem acompanhantes como um ponto de
referência. Nada mais do que eu estou ciente nas mesmas linhas está prontamente
disponível para uso público (PRISM, o software anexado ao IRENE , não é). Há programas
em abundância por aí para converter imagens em áudio, mas praticamente todos tratam
imagens de origem espectrograficamente, como gráficos de tempo e frequência -
Photosounder é um excelente exemplo - em vez de oscilograficamente, como gráficos de
tempo e amplitude.

No entanto, aprendi desde então sobre alguns ambientes de computação numérica e

linguagens de programação que podem inserir e produzir arquivos de imagem e áudio com
flexibilidade, enquanto realizo cálculos elaborados entre eles, e decidi ver se eu poderia
aproveitar um deles como um substitua por ImageToSound. Das opções disponíveis -
incluindo o MATLAB - acabei indo com o GNU Octave , que é gratuito e de código aberto.
Também é conveniente: eu baixei e executei o mais recente instalador oficial do Windows e
coloquei tudo em prática em instantes. Aqui está o que você vê quando inicia a GUI do
Windows:

Agora você pode inserir comandos no cursor na janela de comando. E aqui está uma
sequência deles que realiza a mesma coisa que eu tenho usado o ImageToSound,
presumindo que a imagem de origem seja em escala de cinza com um eixo de tempo
horizontal:

“
F = imread (“C: / sourcefile.tif ”);
F = duplo (F);
S = soma (F, 1);
U = (S-min (S)) ./ (0,5. * (Max (S) -min (S)) - 1;
wavwrite (U, 44100,24, “C: / targetfile.wav ”);

A primeira linha importa o arquivo de imagem como uma matriz F de números

representando intensidades de pixel. Pense nisso como uma grade na qual as colunas
representam colunas de pixels e as linhas representam linhas de pixels, e nas quais
podemos chamar o valor de uma determinada célula, coluna ou linha e realizar os cálculos
que quisermos. A próxima linha converte todos os números na matriz em formato de
precisão dupla para remover quaisquer restrições impostas a eles como dados de pixel,
como a restrição a números inteiros (que eu descobri pode ser transportada para cálculos
subseqüentes se não os elevarmos ). A terceira linha cria um vetor de linha S - que é o que
uma matriz é chamada se tiver apenas uma linha - da soma das intensidades de pixel de
cada coluna. A quarta linha redimensiona o resultado para o intervalo -1 a +1 dos valores
requeridos pelo formato WAV, atribuir a letra U ao vetor reescalonado; e a quinta linha
grava vetor U em um arquivo WAV de 24.1k de 24 bits com o nome especificado.

Dependendo do que você escolher para uma imagem de origem, poderá receber uma
mensagem como esta:

“
aviso: sua versão do GraphicsMagick limita as imagens a 16 bits por
pixel

Octave irá processar sua imagem de qualquer maneira, mas aparentemente ela não tirará
proveito de qualquer resolução disponível além de dezesseis bits por pixel. Para explorar
resoluções mais altas, é possível reconstruir GraphicsMagick com uma profundidade
quântica de 32 bits - veja a discussão aqui -, mas eu ainda não tentei isso. Dezesseis bits
por pixel realmente não são muito ruins.

Para os meus propósitos, o que acabei de descrever já é uma melhoria no ImageToSound,

que insiste em uma imagem de origem BMP de 24 bits, só pode gerar um arquivo WAV de
8 bits e reduz o deslocamento DC de uma maneira misteriosa e não especificada. Agora
podemos processar praticamente qualquer formato de imagem comum, produzir um
arquivo em qualquer taxa de bits desejada e manipular o deslocamento DC de acordo com
algum procedimento transparente de nossa própria escolha. Então, se você está
procurando uma maneira de fazer o que eu descrevi usando o ImageToSound para fazer
no passado, as cinco linhas de código mostradas acima permitirão que você faça isso de
maneira mais flexível e transparente no Octave.

Mas agora que conseguimos reduzir o tempo e começamos a criar algoritmos de imagem
para áudio, não há razão para pararmos lá. Eu convertei linhas onduladas em faixas
brilhantes de largura variável para conversão para WAV no passado, principalmente porque
esse era o único tipo de entrada que eu poderia encontrar software pronto para manipular.
No entanto, agora eu criei uma maneira razoavelmente simples para evitar a etapa de
edição de gráficos e converter linhas onduladas diretamente em áudio usando o Octave.
Abaixo estão algumas linhas de código que traduzem uma imagem em tons de cinza de um
traço de luz em um fundo escuro com um eixo de tempo horizontal em um arquivo WAV.
“
F = imread (“C: / sourcefile.tif ”);
F = duplo (F);
S = soma (F, 1);
Q = (F./S);
Q (isnan (Q)) = 0;
Z (1: (linhas (F))) = 1: linhas (F);
Z = rot90 (Z, 1);
Y = (Z * Q);
W = soma (Y, 1);
V = (W-min (W)) ./ (0,5. * (Max (W) -min (W))) - 1;
wavwrite (V, 44100,24, "C: / targetfile.wav ");

The first three lines are the same as before. But the fourth line creates a matrix Q of
individual pixel intensities (in matrix F) divided by total column intensity (in vector S), while
the fifth line cleans up any cases where this would entail division by zero by substituting a
zero for each “NaN” (“Not a Number”) value. Lines six and seven then create a column
vector Z of descending row numbers; line eight calculates a matrix Y by multiplying the
fractional pixel intensities in matrix Q by the row numbers in vector Z; and line nine creates
a row vector W from the sums of each column in matrix Y, which we proceed to rescale to
the range -1 to +1 as row vector V and write to a WAV file as before.

To illustrate what this sequence of steps accomplishes, let’s consider how it would handle
an exceedingly simple case: a row of five columns (presuming a vertical time axis) in which
0% of total pixel intensity is in Column 1, 20% in Column 2, 40% in Column 3, 30% in
Column 4, and 10% in Column 5.

When we multiply the column numbers by the fractions of total pixel intensity, the results are
0, 0.4, 1.2, 1.2, and 0.5; and if we sum those we get 3.3. Relative to the positions of the five
columns (marked above with red lines), 3.3 (marked above with a green line) represents the
center of total pixel intensity (represented above in yellow); thus, there should be an equal
area of yellow on either side of the green line. Or, if we want to visualize things relative to
some actual pixel intensity values:

For want of greater precision in our data, we’re inferring that the source trace would have
looked something vaguely like what I’ve shown below before pixelation (the light orange
marks the positions of the five scan lines, while the green line once again marks the center):

When we apply this same principle to an image of the wavy line of a phonautogram, or
something similar, it will return the center location of quantified brightness at each point
along the time axis, which should ideally correspond to the center of the trace (although in
practice visual background noise and imperfections or irregularities within the trace itself
can complicate things).

We shouldn’t necessarily evaluate numerical pixel intensity values in the linear fashion I’ve
described so far. I’ve found through trial and error that results can often be dramatically
improved by raising the original pixel intensity values to a certain power before
carrying out the calculations. Here’s how we would raise them to the power of ten, which
can yield good results:

“ F=imread(“C:/sourcefile.tif”);
F=double(F);
F=F^10;
S=sum(F,1);

[and so on]

The optimal power value will vary from case to case, but it looks like there will be a sweet
spot each time where noise is most fully attenuated, and beyond which raising the power
further will only add noise. Here’s an animation that shows some typical effects of raising
the power of source pixel intensities incrementally by values up to 100:

And here’s the source image for comparison, excerpted from one of Eli Whitney Blake, Jr.’s
1878 photographic sound recordings of the phrase “Brown University” (with height and
width adjusted here to match the scale of the waveform view above):
Larger flecks of visual background noise sometimes produce deflections in the WAV output
which could be got rid of by manually cleaning up the source image beforehand. But the
single most consistent and conspicuous glitch in the audio actually comes from an azimuth
problem where the trace itself runs slightly backwards in time:

O que quer dizer que o método em si parece estar funcionando como pretendido aqui: ele
está identificando o centro de brilho em cada coluna de pixel. Há apenas alguns problemas
com este rastreio de origem específico que não tentamos corrigir e que minha técnica
anterior usando o ImageToSound não teria tratado melhor. Com um rastreamento limpo e
bem formado, essa nova abordagem deve produzir resultados sólidos; e quando não
tivermos muita sorte em nosso material de origem, ele ainda será capaz de lidar com
qualquer coisa que pudermos lançar de uma maneira lógica e consistente, não importa o
quanto seja confuso, assim como minha técnica anterior.

Eu tenho focado aqui na etapa crucial de converter arquivos de imagem em arquivos de

som, mas o Octave também pode ser usado para fazer outros tipos de processamento de
áudio relacionado. Podemos ler em um arquivo WAV com a mesma facilidade com que
podemos um arquivo de imagem:
“
A = wavread (“C: / sourcefile.wav ”);

[A, samplerate, bitdepth] = wavread (“C: / sourcefile.wav ”);

[A, samplerate, bitdepth] = wavread (“C: / sourcefile.wav ”);

wavwrite (A, samplerate, bitdepth, ”C: / duplicate.wav ”);

A primeira variante importa o arquivo WAV como um vetor de coluna A (ou se é um arquivo
multicanal, como uma matriz A com canais atribuídos a colunas diferentes e amostras
sucessivas atribuídas a linhas sucessivas - para um arquivo estéreo, a primeira coluna é a
canal direito e a segunda coluna é o canal esquerdo). A segunda variante faz a mesma
coisa ao mesmo tempo que configura samplerate igual à taxa de amostragem e
bitdepthigual à profundidade do bit. A terceira variante importa um arquivo WAV e, em
seguida, exporta uma duplicata dele, como confirmei por meio da experiência. Então, uma
vez lidos em um arquivo WAV, podemos processá-lo de maneiras que podem ser menos
convenientes, ou mesmo impossíveis, usando um software de edição de áudio comum. Por
exemplo, para converter dados de deslocamento em dados de velocidade - como discuti
aqui, de forma mais indireta, há alguns meses - o comando para tomar a derivada de A é
simplesmente:

“
D = diff (A);

Para ir na direção oposta, de velocidade para deslocamento - que eu nunca consegui

descobrir como realizar amostra por amostra usando software de edição de áudio padrão -
podemos fazer isso:

“ R (1) = A (1);
para i = 2: (comprimento (D) +1);
R (i) = R (i-1) + D (i-1);
endfor;

I’m not really digressing, by the way, since these are both steps we’ll sometimes want to
carry out on the raw results we get from converting a picture of a sound wave into audio.

Picture Kymophone

It’s possible to convert images into audio using Octave by entering commands one by one
at the command prompt, as I’ve been describing. But it’s tedious and inefficient to key
these sequences in by hand over and over again, so I started piecing together a reusable
“function” to take care of them for me automatically. Over time, as I’ve added in more
features and customizable options, this has grown into several hundred lines of code which
I call Picture Kymophone 1.0. You can download it in a zip file here. (It’s furnished with
no warranty of any kind: use at your own risk.)

To run Picture Kymophone it in its simplest form, place picky.m in a directory somewhere
agreeable to you, navigate to it (e.g., in the Octave GUI File Browse window), and then
enter picky at the Octave command prompt. You’ll then be asked to select an image file to
process. Keep in mind that the function assumes the smaller dimension represents
amplitude, the larger dimension represents time, the time scale runs from left to right or top
to bottom, and the trace is light against a dark background (if it’s not, invert it before
processing). Also, if the image file contains multiple channels, such as RGB, they’ll all be
summed indiscriminately to grayscale. Anyhow, once you’ve selected your source image, it
will get processed and you’ll receive a notification like this:

sourcefile.tif processado mode_0_w_all ID = 1478341446

Haverá agora quatro arquivos WAV no mesmo diretório que picky.m , com nomes de
arquivos deste formulário:

sourcefile_1478341446_pdp.wav
sourcefile_1478341446_pvl.wav
sourcefile_1478341446_idp.wav
sourcefile_1478341446_ivl.wav

"1478341446" é simplesmente uma referência de tempo que indica quando os WAVs foram
gerados - útil para acompanhar os resultados de experiências sucessivas - enquanto
"sourcefile" é o nome da imagem de origem truncada no primeiro período. O elemento final
no nome do arquivo mostra o que as amostras no arquivo representam:

pdp = deslocamento de posição (valores posicionais brutos)

pvl = velocidade de posição (derivada / taxa de variação dos valores posicionais)
idp = deslocamento de intensidade (valores de intensidade bruta)
ivl = intensidade da velocidade (derivada / taxa de variação dos valores de
intensidade)

O arquivo idp é equivalente à saída do ImageToSound.

É assim que o Picture Kymophone é executado por padrão, mas você também pode
personalizar um número de variáveis no prompt de comando, assim:

>> exigente w 0 1 d 1 1 0,95 todos 44100 24 c: / sourcefile.tif

Eu gostaria de poder oferecer uma boa interface gráfica com botões de rádio e assim por
diante, mas no momento, é isso que eu tenho. Uma lista de pdf em uma página acessível
de comandos está disponível aqui . Os onze argumentos precisam aparecer na ordem
exata mostrada e especificam:

1. Tipo de saída solicitada, padrão w (para WAV).

2. Modo de processamento, padrão 0 (processamento independente de uma única
imagem de origem).
3. Potência na qual os valores de intensidade do pixel de origem serão aumentados
antes dos cálculos serem executados (1 = linear, 2 = valores ao quadrado, 3 =
valores ao cubo, etc.), padrão 1 (linear).
 4. Configuração de formato numérico a ser usada para cálculos, padrão d
(processamento padrão com precisão dupla).
5. Ajuste de inclinação e deslocamento CC, padrão 1 (sem ajuste).
6. Limiar de amplitude decimal para rejeição de impulso de amostra a amostra (por
exemplo, uma configuração de 0,1 detectaria e removeria quaisquer valores maiores
que 10% da amplitude total dos arquivos de velocidade derivada, e os arquivos de
deslocamento seriam então reintegrados dos resultados); padrão 1 (sem rejeição de
impulso).
7. Valor decimal (por exemplo, 0,1 = 10%) para o qual os valores de amplitude serão
normalizados para saída de WAV (alternativamente, um valor maior que 1 forçará o
recorte); padrão 0,95 (normalização para 95%).
8. O (s) tipo (s) de saída do WAV a ser gerado ( todos, pdp, pvl, idp, ivl, pos =
posição, vel = velocidade, int = intensidade, dis = deslocamento); para suprimir
toda a saída do arquivo WAV, insira qualquer outro grupo de três caracteres. O
padrão é tudo .
9. Taxa de amostragem do arquivo WAV de saída, padrão 44100 .
10. Profundidade de bits do arquivo WAV de saída, padrão 24 .
11. Caminho do arquivo da imagem de origem (caso contrário, o usuário é solicitado a
navegar para o (s) arquivo (s)).

Se você inserir valores apenas para algumas das variáveis, a função atribuirá valores
padrão a todas as variáveis subseqüentes. Então, por exemplo:

>> exigente w 0 10

Isso faria com que a função aumentasse os valores de intensidade de pixel para a potência
de dez antes de executar seus cálculos enquanto revertia para os padrões de todos os
outros parâmetros. Ou para limitar a saída WAV ao arquivo "pdp" enquanto nada muda,
você deve digitar:

>> exigente w 0 1 d 1 1 0,95 pdp

A configuração do formato numérico (argumento # 4) tem implicações sobre a quantidade

de memória necessária e, portanto, se haverá o suficiente para fazer o que você estiver
tentando fazer. O padrão é d minúsculo para o formato de precisão dupla. No entanto, se
você estiver tentando processar uma imagem com uma dimensão de amplitude
incomumente grande, o Octave poderá causar um erro de falta de memória porque você
excedeu o limite padrão de 2 Gb para o tamanho da matriz. Nesse caso, você pode tentar
reduzir a quantidade de memória sendo usada selecionando s minúsculaspara formato de
precisão única. A desvantagem dessa abordagem é que o formato de precisão única não
pode acomodar um intervalo de valores tão amplo quanto o formato de precisão dupla.
Assim, se você estiver aumentando simultaneamente os valores de intensidade de pixel
para um poder relativamente alto, como dez, provavelmente excederá o máximo para um
valor de precisão única, e o Octave parece lidar com essa situação retornando uma matriz
ou vetor consistindo em nada além de zeros, o que significa que a saída WAV será uma
"linha fixa" silenciosa. Configurei a Picture Kymophone para emitir um alerta se isso
acontecer:
“
>> picky w 0 10 s
sourcefile.tif processado mode_0_w_all ID = 1478958141
O intervalo do valor de saída para ( sourcefile.tif ) é zero; recomendar
repetir com configuração de formato numérico diferente

If you don’t want to downsample your source image, one option would be to build Octave to
allow for larger arrays than 2 Gb, but this looks like a lot of work and I haven’t tried it. As an
alternative, I created two alternative numerical format settings you can invoke with upper-
case D or S. Instead of running calculations on a whole array at once, which is where the
memory problems often arise, these options loop through each of the columns separately in
turn. The trade-off is that the processing takes a bit longer. But if a memory error occurs
when Octave is initially reading the image file, then you’re out of luck and may just need to
scale down your image somehow.

Now let’s consider the processing mode (argument #2). Sometimes we simply want to
convert a single image file into audio, but sometimes we want to tackle a whole group of
images at once (such as separate rotations of a phonautogram or revolutions of a disc after
a polar-to-rectangular-coordinates transform), and we may also want to process them in a
mutually consistent way. With that in mind, I’ve provided for a few different processing
options:

0 = Images are processed independently from one another, and auto-generated

range values aren’t saved.
1 = Images are processed independently from one another, but auto-detected range
values are saved for future reference. This creates four tiny working files in the same
directory with picky.m, called ndif.mat, sdif.mat, tdif.mat, and wdif.mat. These
store the maximum group range values for the ivl, idp, pvl, and pdp transductions
respectively.
2 = Images are processed independently from one another, and auto-detected range
values overwrite previously saved ones if and when they exceed them.
3 = Images are processed using saved range values instead of auto-detected ones,
with headroom added at top and bottom as needed.

So let’s say we have five separate image files representing successive parts of a given
recording. First we process the images once without generating any WAVs, the first in
mode 1 and the remaining four in mode 2; and then we generate the output WAV files while
processing all five images a second time in mode 3, applying the data we collected about
the cumulative maximum amplitude range during the first pass. This would be cumbersome
to do manually, but I’ve created some additional processing modes to support different kinds
of batch processing:

50 = Processes a group of source images independently from one another.

51 = Processes a group of source images at mutually consistent amplitude levels
according to the method described above (using processing modes 1+2 for a “test”
pass and then 3 for a second pass).
52 = Processes a group of source images using previously saved amplitude level
ranges.

Here are the options for output type (argument #1):

 w = Outputs a separate mono WAV file for each processed image.
v = Outputs a separate vector for each processed image (pdp = vector W stored in
w.mat; idp = vector S stored in s.mat; pvl = vector T stored in t.mat; ivl = vector N
stored in n.mat)—intended to support further analysis and processing, and used for
intermediate steps during batch processing.
x = Outputs a single concatenated mono WAV file from all processed images, with a
filename of the form Batch_1478341446_pdp.wav, plus a mono “click” file
documenting the join points (Batch_1478341446_clk.wav).
b (ainda não testado) = Gera um único vetor concatenado para cada imagem
processada, mais um vetor de “clique” para referência ( arquivo de clique do vetor
armazenado em clk.mat ) - projetado para suportar análise e processamento
adicionais. O nome do arquivo tem um formato como wconc.mat , sconc.mat , etc.,
armazenando vetor Wconc , Sconc etc.
s = Envia um único arquivo WAV estéreo concatenado de todas as imagens
processadas com os resultados no canal esquerdo e clica no canal direito que
documenta os pontos de junção. O nome do arquivo assume o formato
Batch_1478341446_pdpst.wav .
m (ainda não testado) = Gera uma matriz na qual cada linha sucessiva corresponde
a uma imagem de origem processada sucessivamente e cada coluna sucessiva
corresponde a uma amostra sucessiva (pdp = matriz Wmx armazenada em
wmatrix.mat ; idp = matriz Smx armazenada em smatrix. mat ; pvl = matriz Tmx
armazenada em tmatrix.mat ; ivl = matriz Nmx armazenada em nmatrix.mat ) -
destinada a suportar análise e processamento adicionais .
h = Mostra uma lista de argumentos de linha de comando disponíveis; a, o, t, p, em
seguida, gera mais detalhes sobre argumentos específicos.

Arquivos WAV e vetores concatenados são preenchidos com 3.000 amostras de silêncio no
início e no final. A referência “arquivo de clique” marca cada segmento concatenado com
um valor de -1 para a última amostra de uma imagem de origem e +1 para a primeira
amostra da próxima, assim:

Finalmente, vamos considerar as opções para ajustar a inclinação e o deslocamento DC

(argumento nº 5). O valor padrão é 1, o que significa que nenhum ajuste será feito, mas os
outros valores associados a ajustes específicos são todos os números primos e, para
combinar várias opções, basta multiplicar seus números (que são classificados novamente
por fatoração primária). Alguns dos ajustes disponíveis operam no nível de imagem única.
A opção 2 aplica um filtro High Pass Pass Butterworth de 20 Hz de segunda ordem a um
único resultado de imagem, enquanto a opção 3 define os pontos inicial e final de uma
única imagem igual a zero. Para fazer as duas coisas ao mesmo tempo, entramos no
produto de 2 vezes 3 = 6; isso primeiro alinhará os terminais e, em seguida, aplicará o filtro
de alta freqüência a eles.

Outros ajustes, ao contrário, operam em resultados no nível de lotes inteiros. A opção 5 é o

equivalente ao resultado do lote da opção 2, e a opção 7 é o equivalente ao resultado do
lote da opção 3. Por outro lado, a opção 11 (“unir”) é exclusiva dos resultados do lote: a
primeira amostra de cada nova imagem. # 2 é igual à última amostra da imagem anterior.

Abaixo está um exemplo real que mostra o recurso de “junção” em ação - é uma sequência
de rotações de uma impressão em papel de um disco de gramofone que sofreu uma
transformação de coordenadas polar para retangular que deixou uma curvatura significativa
em cada rotação.

A forma de onda no topo mostra as rotações concatenadas sem ajuste, enquanto a forma
de onda abaixo mostra os resultados ajustados, com uma “trilha de clique” abaixo para
mostrar onde os segmentos foram costurados juntos. A faixa de amplitude exportada do
sinal significativo é minúscula aqui em relação à curvatura rotacional, que não é tão boa
para nossos níveis, mesmo com resolução de 24 ou 32 bits, mas podemos melhorar as
coisas implementando um filtro de 20 Hz antes da exportação, que é precisamente o
cenário em que construí essa funcionalidade para abordar. Os cliques descendente
representam quebras no traço original e podem ser facilmente removidos com ferramentas
padrão de atenuação de ruído por impulso.

Resultados da Amostra

Eu ainda estou me experimentando com como obter os melhores resultados do Picture

Kymophone, mas eu seria negligente em não oferecer pelo menos alguns exemplos de
sons que eu usei para processar. Há alguns meses atrás, escrevi sobre um disco feito em
1878 por Étienne-Jules Marey sobre a descarga elétrica de um peixe-torpedo, que converti
em áudio usando minha velha técnica:

Para ver como a Picture Kymophone lidaria com isso, juntei os três segmentos numerados
à mão em uma única faixa longa e estreita, apaguei apenas os numerais e a dúzia de
partículas de ruído visual e processei o resultado editado usando este comando:

“
exigente w 0 10 d 1 1 0,95 pdp 25770

Isso instrui o Picture Kymophone a gerar:

um único arquivo WAV ( w )

a partir de uma única imagem processada de forma independente ( 0 )
com valores de intensidade de pixel aumentados para a décima potência ( 10 )
usando o formato de número de precisão dupla, já que o arquivo de imagem é
pequeno o suficiente para não causar problemas de memória ( d )
sem ajuste de compensação CC ( 1 )
e sem rejeição de impulso ( 1 )
normalizado para 95% ( 0,95 )
retornando amostras que representam o deslocamento posicional ( pdp )
a uma taxa de amostragem fora do padrão de 25.770 amostras por segundo, com
base em uma escala na imagem de origem que equivale a uma linha de 2.577 pixels
de comprimento a 1/10 de segundo ( 25770 )
na profundidade de bits padrão de 24 bits

Em seguida, passei mais quinze minutos limpando a imagem um pouco mais

meticulosamente no Photoshop e processei os resultados novamente usando o mesmo
comando. Aqui está um arquivo de som com (1) o áudio da primeira passagem, (2) o áudio
da segunda passagem após a limpeza manual e (3) o áudio da segunda passagem após
uma ferramenta padrão de remoção de ruído por impulso ter sido aplicada isto:

00:00 00:00

Cleaning up images in graphics editing software before processing them still improves our
results—I haven’t rendered that step obsolete, much as I’d like to. However, getting to hear
something out of an image takes a lot less work now than it did before with my earlier
technique. That makes it much more feasible to test-play a waveform picture and get a
sense for what it will sound like before investing serious time in it.

Next, here’s a source that didn’t lend itself well to my earlier technique: a recording Dayton
Miller made with his phonodeik on May 18, 1909, of himself saying “Lord Rayleigh,”
reproduced as a halftone illustration in his book The Science of Musical Sounds (published
1922, on page 238).

As cristas e vales estão claramente marcados aqui, mas não há muito de um traço de
conexão entre eles. A reprodução dessa gravação usando minha técnica antiga exigiria a
incorporação de cada crista e vale manualmente no Photoshop para criar um limite claro
capaz de conter a ação da ferramenta paintbucket. Mas o Picture Kymophone não precisa
de um limite para encontrar o centro de brilho em cada coluna de pixel. Então eu consegui
unir as duas imagens - há uma pequena sobreposição entre elas - e depois processá-las
em áudio em alguns segundos (marcas representando centésimos de segundo estão
espaçadas em intervalos de aproximadamente 157,2 pixels, daí a taxa de amostragem):

“
exigente w 0 20 d 1 1 0,95 pos 15720

Aqui está o resultado em um arquivo de som com (1) amostras baseadas em deslocamento
e (2) amostras baseadas em velocidade.
 00:00 00:00

Em seguida, vamos tentar algum processamento em lote. Com a minha nova ferramenta
na mão, voltei para o trabalho de preparação que eu já havia feito há alguns anos em uma
impressão de papel de um disco de gramofone em um álbum de recortes nos jornais Emile
Berliner na Biblioteca do Congresso, o “Schalldruck” de novembro. 11 de janeiro de 1889:

Eu já havia feito alguma limpeza básica no traçado enquanto ainda era uma espiral,
converti a espiral em linhas paralelas usando uma transformação de coordenadas polar
para retangular e, em seguida, isolei cada uma das 124 rotações em um arquivo de
imagem separado. Da última vez, usando o ImageToSound, eu também precisei gastar
bastante tempo pesquisando o rastreamento de intervalos e juntando-os, além de unir
todas as rotações separadas à mão. Mas desta vez eu coloquei as 124 imagens separadas
em uma pasta como TIFs e executei este comando:

“
exigente x 51 10 d 330 0,008 0,95 pdp 26460

Esse comando instrui o Picture Kymophone a criar:

um único arquivo WAV mono concatenado, além de um arquivo “click” separado

para referência ( x )
de um lote de imagens processadas com um intervalo de amplitude de detecção
automática consistente ( 51 )
com valores de intensidade de pixel aumentados para a décima potência ( 10 )
usando o formato de número de precisão dupla, uma vez que os arquivos de
imagem são pequenos o suficiente para não causar problemas de memória ( d )
com um filtro de alta freqüência de 20 Hz aplicado nos níveis de imagem única (2) e
lote (5) e com pontos de extremidade de imagem única ajustados previamente a
zero (3) e unidos no nível de lote (11) caso eles Já comecei nesse meio tempo ( 2 *
3 * 5 * 11 = 330 )
 ignorando qualquer salto entre amostras maior que 0,8% da amplitude total da
amplitude, um valor resolvido através de tentativa e erro ( 0,008 )
normalizado para 95% ( 0,95 )
retornando amostras que representam o deslocamento posicional ( pdp )
a uma taxa de amostragem fora do padrão de 26.460 amostras por segundo, já que
cada revolução ocupa 30.000 pixels e nossa velocidade alvo é de 50 rpm ( 26460 )
na profundidade de bits padrão de 24 bits

Aqui está o resultado:

00:00 00:00

O tempo de processamento no meu laptop foi de aproximadamente 26 minutos.

Finalmente, eu reprocipei algumas imagens limpas que eu já tinha em mãos para o famoso
9a 9 de abril de 1860 do Au Clair de la Lune, usando este comando (note a maiúscula D
para acomodar arquivos de imagem extraordinariamente grandes):

“ picky s 51 10 D 2

Eu não tenho corrigido a velocidade dos resultados, porque eu sou otimista, eu vou ser
capaz de implementar um algoritmo de correção de velocidade no Octave também, e eu
prefiro dedicar qualquer tempo que eu tenho livre para tais coisas do que para corrigir
arquivos à mão como eu fiz no passado. Os seguintes arquivos de som, portanto, exibem
extrema irregularidade na velocidade de gravação. Eles também combinam um registro
da voz no canal esquerdo com um registro traçado simultaneamente por um diapasão no
canal direito. Com essas ressalvas, aqui está uma transdução de deslocamento (que se
tornou o padrão tradicional para os fonoautogramas):

00:00 00:00

E aqui está uma transdução de velocidade (aproximadamente o que teríamos se

pudéssemos de alguma forma rastrear o fonoautograma fisicamente com uma caneta
ligada a uma captadora eletromagnética moderna):

00:00 00:00

Quer experimentar o software você mesmo, mas não tem nenhuma foto adequada à mão
para experimentar? Você é bem-vindo a praticar na imagem de exemplo abaixo, que é uma
varredura de 1200 dpi da vogal “o” como gravada por William Preece e Augustus Stroh em
algum momento antes de fevereiro de 1879, invertida de escuro sobre luz para claro sobre
o escuro mas de outro modo inalterado. (Veja a fonte no contexto aqui .)
Se você decidir dar uma reviravolta na Picture Kymophone, eu apreciaria um relatório de
suas experiências e resultados, sejam eles positivos ou negativos. E se alguém lá fora
puder descobrir uma maneira de construir uma interface de usuário mais conveniente, isso
também seria ótimo.

Anúncios

Denunciar este anúncio

Denunciar este anúncio

Compartilhar isso:

 O email  Tumblr  Impressão  Pinterest  Reddit  Twitter

 Facebook  Google

Like
2 bloggers like this.

20 de novembro de 2016 em Técnicas de Edução . Tags: GNU Octave , ImageToSound , Picture

Kymophone , Software , Sonificação , Técnicas de Educação

Posts relacionados

Como "reproduzir" uma imagem de uma onda sonora