UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA
CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
Vinicius Bezerra Araujo da Silva
Sistema de Play-Along com Source Separation Integrado
RECIFE 2020
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
Vinicius Bezerra Araujo da Silva
Sistema de Play-Along com Source Separation Integrado
Monografia apresentada ao Centro de Informática (CIN) da Universidade Federal de Pernambuco (UFPE), como requisito parcial para conclusão do Curso de Engenharia da Computação, orientada pelo professor Giordano Ribeiro.
RECIFE 2020
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
Vinicius Bezerra Araujo da Silva
Sistema de Play-Along com Source Separation Integrado
Monografia submetida ao corpo docente da Universidade Federal de Pernambuco, defendida e aprovada em 27 de Novembro de 2020.
Banca Examinadora:
Orientador XXXXXX
Doutor
Examinador XXXXXXX
Doutor
AGRADECIMENTOS
Queria agradecer primeiramente a Deus por iluminar meus passos apesar de todas as reviravoltas e sempre fazer acreditar que vou conseguir. Em seguida preciso agradecer a minha família, principalmente minha mãe e meu pai que nunca deixam de me apoiar em nada que escolho fazer. Também sou grato as amizades que cruzaram e permaneceram comigo nessa caminhada, além dos professores como o professor Giordano e Filipe Calegario, que sempre estão dispostos a acrescentar na minha vida acadêmica.
13
RESUMO
Source Separation é um desafio que tem várias aplicações e é conhecido há algumas décadas na área de computação musical e processamento de áudio. Com o advento de algoritmos de redes neurais profundas, desenvolveu-se técnicas de Source Separation que se mostraram promissoras. A Deezer desenvolveu uma ferramenta Open Source de Source Separation usando algoritmos de redes profundas chamada Spleeter. Este trabalho tem como objetivo criar uma ferramenta de aprendizado e experimentação musical a partir de um aplicativo móvel que possui um sistema de Source Separation integrado, Spleeter, utilizando a plataforma iOS.
Palavras-chave: Source Separation, play-along, aprendizagem.
14
ABSTRACT
Source Separation is a challenge that has several applications and has been known for some decades in the field of music computing and audio processing. With the advent of deep neural network algorithms, Source Separation techniques has been developed that has shown good results. Deezer developed an Open Source Source Separation tool using deep network algorithms called Spleeter. This work aims to create a musical learning and experimentation tool from a mobile application that has an integrated Source Separation system, Spleeter, using the iOS platform.
Keywords: Source Separation, play-along, musical learning.
15
Sumário
1. Introdução 18
2. Problema 20
3. Estado da Arte 20
3.1. Aprendizagem de máquina 21
3.1.1. Algoritmos supervisionados 21
3.1.2. Algoritmos não-supervisionados 22
3.2. Redes Profundas 23
3.2.1. Open Unmix 23
3.2.2. Spleeter 25
4. Proposta de Solução 27
4.1. App 27
4.2. WebService 30
5. Avaliação 31
5.1. Experimentos 31
5.2. Relatos 31
6. Conclusões 33
6.1. Trabalhos Futuros 33
7. Bibliografia 33
16
Lista de Figuras
Figura 1. Software de gravação mixando diferentes pistas gravadas separadamente. 19
Figura 2. Exemplo de classificação com SVM 21
Figura 3. Exemplo de classificação com GMM 22
Figura 4. Diagrama de Beamforming 23
Figura 5. Modelo de célula de LSTM 24
Figura 6. Exemplo de arquitetura de U-Net 26
Figura 7. Resultados do Spleeter comparado ao Open-Unmix 26
Figura 8. Tela de busca do aplicativo 28
Figura 9. Tela de detalhes do aplicativo 28
Figura 10. Tela de status do aplicativo 29
Figura 11. Tela do player do aplicativo 29
17
1. Introdução
Temos acesso a uma biblioteca vasta de música na palma da mão através dos smartphones e serviços de streaming, porém. nem sempre foi assim. Foi um processo longo de evolução para chegar nesse estágio atual. A primeira gravação, que se tem registro, aconteceu no século XIX, mais precisamente em 1877 pelo inventor da lâmpada e do telégrafo, Thomas Edison. O aparelho captava o som através de um cone, que por sua vez fazia um diafragma vibrar. Uma agulha gravava fisicamente as vibrações captadas num cilindro de alumínio.
Essa técnica seguiu evoluindo por outros cientistas. O disco de vinil, que foi bastante popular, é baseado nessa ideia. A agulha percorre o vinil captando mecanicamente as vibrações registradas no vinil e com isso a máquina converte as vibrações em sinal de áudio.
Já as fitas partiam de uma proposta diferente, formava-se o início da era digital. Possuíam uma camada de óxido de ferro, Fe2O3 , que é um composto ferromagnético e podia ser gravado permanentemente através de campos magnéticos. Então a fita era gravada e depois lida a uma velocidade constante e esse sinal digital era traduzido em sinal de áudio pelas máquinas leitoras de fita.
A era digital incentivou outros desafios a serem atacados. Fazer a engenharia reversa, ou pensar em extrair alguma característica de uma música gravada analogicamente era muito mais desafiador. Nos dias de hoje é possível encontrar algumas aplicações que foram criadas a partir desses desafios como play-alongs, mixagens, remixagens e etc.
Como pode-se definir uma música através dessa ótica? Uma música é geralmente composta por um mix de pistas individuais de outros instrumentos como, por exemplo, vozes, piano, bateria e etc. Já um play-along pode ser definido como uma música, composta por um conjunto de faixas como mencionado, porém com o diferencial de uma ou mais pistas silenciadas. Desse modo, o play-along sugere o usuário tocar a pista silenciada fazendo o sentimento de se sentir parte da música mais aflorado ou até mesmo realizar estudos mais direcionados.
Sobre o conceito de pistas, uma vez mixadas essas pistas se tornam uma única faixa com sua forma de onda particular. Sem o acesso às pistas individuais, percebe-se mais um desafio. Como separar novamente as pistas? Como fazer o Source Separation? Essa questão existe há algumas décadas e tem algumas potenciais aplicações como propósitos educacionais, como os play-along, e até pré-processamento das ondas para transcrições.
18
Figura 1. Software de gravação mixando diferentes pistas gravadas separadamente.
Para este trabalho categorizou-se as abordagens sobre esta temática de Source Separation como orientado a dados e não orientado a dados. Sobre os algoritmos não orientados a dados, ou clássicos, pode-se resumir em três principais conceitos: Processamento de Sinal, Modelagem de Áudio e Teoria da Probabilidade, segundo Zafar Rafii et al.(2018).
Contudo, com o advento das redes neurais, algoritmos orientados a dados têm se mostrado relevante neste desafio e há algum tempo tem ultrapassado os resultados comparados aos não-orientado a dados. A equipe de pesquisadores da Deezer construiu uma ferramenta chamada Spleeter, que é baseada em redes neurais profundas, que mostrou resultados interessantes comparado ao algoritmo atual do estado da arte, o Open-Unmix, segundo Romain Hennequin et al.(2020).
Com ferramentas como esta e com a disponibilidade de material na internet, despertou-se uma questão. Por que não aliar smartphones para atacar algumas lacunas da música moderna como play-alongs? Na seção 2 é levantado questões a serem trabalhadas sobre esse tema. Já na seção 3 é mencionado o estado da arte atual e por que este trabalho poderia contribuir no tema. A seção 4 é apresentado a proposta de solução e os resultados com avaliações são encontrados na seção 5. Na seção 6 tem a conclusão deste trabalho.
19
2. Problema
Existem vários aspectos a serem mencionados quando se fala de play-along nos dias de hoje. É verdade que é possível encontrar material disponível pela internet através do youtube, por exemplo, porém com uma qualidade inferior aos play-alongs produzidos em estúdio.
Outro ponto pertinente a ser levantado, além da qualidade, é sobre a disponibilidade desse material. Nem sempre é possível encontrar um play-along de determinado instrumento, ou determinada música. Os direitos legais e de copyright também engessam bastante a avaliabilidade das pistas. Isso faz o usuário depender da disponibilidade de play-alongs existentes no mercado, ou, de músicos para gravarem as pistas, que, envolveria um investimento financeiro. Maior parte dos play-alongs profissionais ou de estúdio não se encontram de graça.
Por outro lado, já existem ferramentas e algoritmos baseados em redes profundas que mostram um resultado expressivo no source separation de uma música, como o Open-Unmix e oSpleeter da Deezer. Isso se deve a alguns artistas que escolhem divulgar suas faixas usando licenças do tipo Creative Commons, que permite compartilhar livremente as pistas. Com isso, base de dados como o MUSDB18 (Rafii et al., 2017) puderam ser construídas e algoritmos orientados a dados puderam evoluir.
Integrar esses serviços juntamente com sistemas móveis, como um smartphone, executando separação automática de várias pistas/instrumentos atacaria diretamente o modo que se faz play-along atualmente. O usuário teria uma gama bem maior de recursos disponíveis para o estudo numa qualidade melhor sem depender de outros fatores externos.
3. Estado da Arte
Pesquisando até o momento não encontrei trabalhos feitos voltados especificamente para sistemas de geração de play-along automático. Contudo há bastante trabalhos na área de Source Separation. O primeiro software publicamente disponível de Source Separation foi o openBlissart, liberado em 2011 (Weninger, Lehmann, & Schuller, 2011). Foi escrito em C++
e baseado em NMF, non-negative matrix factorization.
20
3.1. Aprendizagem de máquina
Resume-se aprendizagem de máquina como algoritmos capazes de fazer previsões e aprender depois de treinados com um conjunto de dados. Pode-se agrupar os algoritmos de aprendizagem de máquina de Source Separation entre Aprendizagem Supervisionada e Aprendizagem não-supervisionada. Os algoritmos de aprendizagem supervisionadas são os algoritmos de aprendizagem de máquina que usam um dataset conhecido com seus rótulos, ou valores esperados para poder treinar e poder validar o treino com os valores esperados. Já os não-supervisionados fazem predições sobre os dados sem ter acesso as respostas. Acontece um processo de treinamento onde pode-se aprimorar parâmetros dos algoritmos de aprendizagem até que ele atinja um nível de precisão desejado.
O algoritmo ainda pode ser de classificação ou de regressão, no qual, regressão o
resultado esperado é geralmente um valor numérico e; classificação o resultado esperado são categorias, nesse contexto por exemplo, pode-se classificar determinada frequência num determinado tempo como sendo da categoria vocais ou percussão.
3.1.1. Algoritmos Supervisionados
Os principais algoritmos supervisionados usados são o SVM, GMM. O Support Vector Machine (SVM) é baseado em classificar dados encontrando um hiperplano que separa os dados. Sua desvantagem é sua complexidade algorítmica quando há muitos dados para classificar, por exemplo mais de 10 mil dados os treinamentos levam dias para acontecer porque o algoritmo testa várias combinações de hiperplanos para separar os pontos.
Figura 2 - Exemplo de classificação com SVM
21
Já o Gaussian Mixture Model (GMM) tenta modelar os dados, cada ponto, através de distribuições gaussianas. Então o algoritmo de expectation maximization, que é um método iterativo de calcular os parâmetros de máxima verossimilhança é usado para aproximar o resultado de um dado sem rótulo e poder classificá-lo. A parte negativa dessa abordagem é que é necessário um grande conjunto de funções gaussianas para mapear cada dado.
Figura 3 - Exemplo de classificação com GMM
3.1.2. Algoritmos Não-Supervisionados
Já os principais algoritmos não-supervisionados são o Non-negative matrix
factorization (NMF), Beamforming e ICA. O NMF tem mostrado bons resultados e é usado em várias aplicações como processamento de imagem, clusterização de documentos e etc. É baseado em um método de aproximação onde a entrada, que deve ser uma matriz
não-negativa, é calculada como um produto de dois fatores matriciais, não-negativos. Um representa os atributos vocais da separação, e o outro fator seria os acompanhamentos. O lado negativo dessa abordagem é que funciona para entradas não-negativas.
O beamforming é baseado no princípio de filtragem espacial. O seu foco é aumentar os sinais advindo de uma determinada direção através de uma configuração de um conjunto de microfones e rejeitar outros sinais. Pode-se conseguir bons resultados com uma boa
configuração de microfones. A desvantagem é que o número de microfones pode aumentar o ruído.
22
Figura 4 - Diagram de Beamforming
Já o Independent Component Analysis (ICA) se trata de um método para separação de sinais multivariados nos seus subcomponentes. O ICA é usando em blind source separation onde nenhuma informação prévia é sabida. O método assume 2 fatores, que podem ser um ponto negativo, pois caso não seja verdadeiro o método não funciona bem. O algoritmo assume que o sinal fonte são independentes entre si e os valores de cada fonte não apresentam distribuições gaussianas.
3.2. Redes Profundas
Com a evolução dos datasets como o MUSDB permitiu-se estudos com redes profundas devido a quantidade de dados disponíveis. Semelhante aos algoritmos de aprendizagem de máquina, redes profundas também são treinadas a partir de um conjunto de dados, porém usa-se uma arquitetura de células que processam os dados, agregam conhecimento e passam para outras camadas e células. Existem várias arquiteturas de redes e várias abordagens porém abordou-se as implementações usadas no Open-Unmix e no Spleeter, que são relevantes para este trabalho.
3.2.1. Open-Unmix
OOpen-Unmix é um framework modular, open-source, desenvolvido emPytorch. Foi construído para poder ser usado como base em outras pesquisas e trabalhos. É baseado em um 23
modelo de três camadas de LSTM bidirecional, desenvolvido pelos pesquisadores Fabian-Robert Stöter e Antoine Liutkus com colaboração de pesquisadores da Sony Corporation, Stefan Uhlich and Yuki Mitsufuji.
O modelo de LSTM se refere a Long short-term memory, redes de memória de curto prazo longo. São um tipo de rede recorrente que tem uma célula especial com capacidade de memorizar informação. A estrutura da célula de uma LSTM baseia-se em alguns gates, ou portões, para calcular o estados de memória da célula.
Figura 5 - modelo de célula de LSTM
O fluxo de processamento inicia no forget gate que calcula, através de uma função sigmóide, que informação deve ser esquecida ou mantida. Já no input gate decide-se como atualizar a informação do nó atual através de funções sigmóide e tanh (tangente hiperbólica).
O resultado do forget gate é agregado ao resultado do input gate e tem-se o novo estado de memória da célula. E por fim o output gatedecide que informação segue para próxima célula através de funções sigmóide e tanh entre o novo estado de memória da célula e da informação inicial de entrada.
Em resumo, o forget gate decide o que é relevante manter das etapas anteriores, o input gate decide que informação é relevante ser adicionada no nó atual e o output gate decide que informação é válida para seguir para o próximo nó. E o diferencial da estrutura bidirecional usada no Open-Unmix é que a informação é processada em dois sentidos, de modo que, a rede consegue processar a informação levando em conta estados no passado e no futuro, devido a bidirecionalidade da rede.
24
Com avanço dos modelos treinados e datasets, em setembro de 2019 o Open-Unmix atingiu o estado-da-arte obtendo resultados comparáveis ou melhores aos do que obteve o melhor desempenho baseado na campanha de avaliação do SiSEC 2018, Signal Separation Evaluation Campaign. Vale salientar que a base de dados usada na avaliação foi o MUSDB18, que conta com 150 músicas com pistas disponíveis, que resulta em aproximadamente 10 horas de música.
3.2.2. Spleeter
No outro lado, o Spleeter é uma biblioteca Python, open-source, baseada em TensorFlow,desenvolvida pela equipe de pesquisadores de Deezer, Romain Hennequin, Anis Khlif, Felix Voituret, Manuel Moussallam. Ela também serve de base para outros trabalhos inclusive os modelos pré treinados do Spleeter estão sendo usados por softwares de áudio profissionais como o iZotope, VirtualDJ, SpectralLayers, Acon Digital, Algoriddim e outros.
Alguns pontos se destacam nesta ferramenta: É mais simples de usar por ser uma biblioteca, basta instalar que tem-se disponível para uso na linha de comando; Para fins com grandes quantidades de dados o Spleeter consegue se destacar na velocidade de processamento, quando se usa GPU, pois seu modelo é baseado em CNN que faz a paralelização ser mais eficiente. CNN se refere a Convolutional Neural Networks, um tipo de rede aplicado geralmente a imagens, que faz convoluções reduzindo escala das imagens e aprendendo features importantes e deixando de lado informações não relevantes.
Para processar áudio, a CNN usada no Spleeter foi arquitetada em forma de U-Net. O áudio é convertido em um vetor, em vez de imagem, através do seu espectrograma e então mapeado em uma escala menor reduzindo sua escala. Essa etapa é chamada de encoder, onde as informações aprendidas são codificadas em etapas menores, semelhante a redução de escala das imagens numa CNN. E após isso existe a etapa de decoder, onde a informação é decodificada e as features aprendidas são agregadas e ampliadas.
Chama-se U-Net pois a rede tem uma forma visual de “U”. O diferencial usado pela equipe da Deezer foi construir a rede para processar tensors de 3 dimensões, no qual um tensor é um objeto básico de dados do TensorFlow. A U-Net da Deezer trabalha com as informações de canais, time steps e frequência como as 3 dimensões; e 12 camadas sendo 6 camadas de encoder e 6 camadas de decoder.
25
Figura 6 - Exemplo de arquitetura de U-Net
Porém, o ponto mais importante a ser mencionado é a performance. O Spleeter consegue resultados mais expressivos que o atual estado-da-arte Open-Unmix, tomando o lugar agora como atual estado-da-arte. Os resultados são mostrados de acordo com as métricas padrão de source separation que são: Signal to Distortion Ratio (SDR), Signal to Artifacts Ratio (SAR), Signal to Interference Ratio (SIR) e source Image to Spatial distortion Ratio (ISR).
Figura 7 - Comparação de resultados Spleeter Soft Mask, Spleeter Multi Channel Wiener Filtering e Open-Unmix.
Devido a facilidade de uso e performance, o Spleeter se mostrou uma ferramenta mais promissora para integrar o sistema desse trabalho.
26
4. Proposta de Solução
Ao usufruir das ferramentas citadas, uma vez que, foram construídas pensando em serem usadas como base de outros trabalhos, o desafio de idealizar e construir um sistema de play-along com source separation integrado se torna menor. Planejou-se integrar o Spleetera um aplicativo móvel iOS para compor este trabalho. Deste modo, espera-se desenvolver um sistema automático de play-along que ataca diretamente os pontos negativos levantados na seção de problema e também mudar a maneira que se estuda música e produz play-along.
A partir disso foi necessário tomar decisões e construir uma arquitetura para tornar possível o sistema. Julguei que não é viável, no tempo deste trabalho, portar o Spleeterpara Swift e rodar tudo com o smartphone iOS. Então, montou-se uma arquitetura de WebService, no qual existe um serviço que roda o source separation e que responde às chamadas do aplicativo. Além disso, escolheu-se construir o serviço web pois pode-se disponibilizar os recursos para várias aplicações diferentes, pensando numa futura expansão. Foi construído na linguagem de Node JS devido principalmente a disponibilidade de bibliotecas e a minha familiaridade com o assunto, em vez de escolher Python, já que o Spleeter roda em Python.
O aplicativo móvel foi pensando para plataformaiOS nativo devido principalmente a minha familiaridade com o assunto e sua performance performance, em vez de, linguagens híbridas comoReact Native. Escolhi também integrar a APIdoYoutubeno devido a variedade de músicas, versões e covers disponíveis.
4.1. App
O aplicativo é a interface do usuário. Construiu-se um fluxo bem direto com 4 telas.
Pensando no processo de como acontece um estudo ou experimentação musical,
primeiramente escolhe-se que música pretende-se estudar. Então a primeira tela compreende a tela de busca da música através da API do Youtube, onde pode-se pesquisar no acervo do Youtube a música por nome.
27
Figura 8 - Tela de busca do aplicativo
Depois da música escolhida, entra a tela de detalhes, onde pode-se assistir a música escolhida e também escolher quantas faixas (stems), pretende-se separar a música. Esses detalhes são importantes o usuário verificar antes clicar em “Spleet” e dar início ao processamento do source separation no serviço.
Figura 9 - Tela de detalhes do aplicativo
Agora que já se sabe qual a música e quantas faixas, a o usuário pode clicar no botão
“Spleet” para dar início no processamento. Uma requisição é enviada ao WebService e pode-se monitorar o status da requisição na tela de status. Mais detalhes da separação é mencionado na seção do WebService.
28
Figura 10 - Tela de status do aplicativo
Depois de processado, o WebService alimenta o aplicativo com as faixas separadas e é carregado a tela com o player. Nesta tela pode-se controlar as pistas separadamente e praticar e experimentar seus estudos com o play-along já pronto para qualquer umas das faixas.
Figura 11 - Tela do player no aplicativo
O player foi construído usando a classe do AVAudioPlayer da biblioteca padrão do AVFoundation da Apple. Os dados das pistas separadas consumidos do serviço são usados para instanciar os AVAudioPlayers de cada pista. Foi necessário também organizar a tocabilidade do player com threads para sincronizar todas as pistas da música em um único player de forma síncrona. Isso foi necessário para garantir que as pistas toquem corretamente sem atrapalhar as funções das threads principais do aplicativo, como atualizações da tela e etc.
29
4.2. WebService
O Serviço web foi construído como uma APIREST e pode ser divido em seus 3 endpoints: /spleet, /status e /streamAudio. Ele é responsável pelas tarefas dentro do sistema como converter a música escolhida do acervo do Youtube, rodar o source separation, além de gerenciar regras de negócios do sistema. Escolhi usar o banco de dados mongoDB e sua biblioteca mongoose para NodeJS para persistir dados e aplicar as regras de negócio, uma vez que, a APIREST por conceito é sem estado, stateless.
O primeiro endpoint, o "/spleet", é chamado na tela de detalhes da música no app. O servidor recebe uma requisição POST com a url da música selecionada e quantas pistas deseja-se a separação. A escolha desse verbo se dá devido as criações de registro feitas no banco, caso a música escolhida nunca tenha sido processada registros são criados para evitar retrabalho. Neste projeto, ficou disponível escolher entre 2 ou 4 pistas sendo 2 pistas como:
Vocal e Acompanhamento; e 4 pistas: Vocais, Bateria, Baixo e Outros.
Com esses parâmetros o sistema cria 1 registro na tabela de "songs" que descreve a entidade da música dentro do sistema. Têm-se os campos de status para 2 pistas, 4 pistas e status do download. Atualmente, para este trabalho as músicas estão sendo salvas localmente e ficam em um lugar fixo identificadas pelo caminho <Npistas>/<idMusica>. Por exemplo, se a música escolhida no youtube tem o id "abc123" e também foi escolhido separar em 2 pistas.
Após o processo, seus arquivos serão salvos no diretório /2stems/abc123.
Após disparar o endpoint "/spleet", o usuário é levado para tela de status onde pode-se acompanhar o status do processamento. Nesta tela o endpoint de "/status" deve ser disparado para atualizar o andamento da requisição. O sistema através do id da música consulta no banco os status de download da música e da separação e devolve ao app para atualizar a interface. Neste cenário o método usado foi o GET, pois trata-se de uma requisição simples sem atualizar ou criar novos registros.
Depois que o processamento é finalizado, é liberado o acesso a tela do player. Ao carregar essa tela o aplicativo dispara o último endpoint, o "/streamAudio". Nessa requisição, o serviço envia as pistas separadas para o aplicativo através de uma requisição GET. Vale salientar que nesse momento foi usado a abstração do pipe do NodeJS. Converte-se o arquivo da música da pista a ser enviada em um stream de leitura e então pode-se "pipear" esses dados para dentro do stream de escrita HTTP enviando assim chunks de bytes do server para o app até completar os arquivos.
30
5. Avaliação
Para avaliar a proposta desenvolvida foi feito entrevistas e validações com 6 usuários.
Os usuários puderam testar o aplicativo móvel remotamente devido ao cenário de pandemia do vírus COVID-19 no momento de execução deste trabalho. A validação teve um objetivo qualitativo onde tentou observar se fazia sentido a interface pro usuário, se o sistema contribuia musicalmente para o estudo ou experimentação do usuário gerando play-alongs automáticos e se os play-alongs eram usáveis.
5.1. Experimento
O ambiente de teste se baseou no simulador de iPhone que rodava na máquina que o trabalho foi desenvolvido. Através de ferramentas de chamadas de vídeo, como o Zoom, os entrevistados eram contactados e então concedido o controle remoto do mouse e teclado da máquina que hospedava o simulador, além do compartilhamento da tela. Desse modo, o aplicativo que rodava no simulador podia ser testado pelos entrevistados.
Os usuários entrevistados têm noção musical, conseguem tocar algum instrumento, e também atuam no ramo de computação musical. Fazem parte da Daccord, que é uma empresa de software de música situada em Recife. Tive acesso aos canais informais de comunicação desse grupo e fiz o convite para entrevista.
5.2. Relatos
Qualitativamente os usuários relataram como positiva a experiência de usar o aplicativo, além de relatar como boa qualidade o play-along criado a partir de músicas escolhidas a seu gosto. Pseudônimos são usados para trazer os relatos dos entrevistados neste trabalho. Alguns usuário fizeram comentários semelhantes, porém foi explicitado os mais relevantes, para os usuários, e diferentes para evitar a repetição desses comentário nos relatos.
Usuário 1 relatou que gostou da fluidez do aplicativo, onde não teve dificuldade de usar. Porém ao escolher uma música que não conhecia, sentiu falta de ver as cifras e ficou sem conseguir tocar junto do play-along. Precisou sair do aplicativo para verificar as cifras e então retornar.
31
Usuário 2 relatou que ficou um pouco “perdido” ao chegar na tela de status do aplicativo. Precisou explicações para entender em que etapa ele se encontrava. Após isso conseguiu seguir o fluxo e relatou como bom o play-along criado.
Usuário 3 conseguiu fazer o fluxo sem problemas e gostou do play-along gerado, porém umas das músicas escolhidas tinha uma abertura feita no violão. Ao silenciar a pista do violão o usuário perdeu a referência de início da música e teve dificuldades para acompanhar o play-along tocando seu violão. Relatou que se tivesse um metrônomo interno ajudaria.
Usuário 4 fez o fluxo sem problemas e achou de boa qualidade o play-along gerado.
Contudo, relatou que gostaria que tivesse um controle de volume das pistas, além do controle de silenciar. Explicou que na música que queria aprender, gostaria que tivesse ainda uma referência de fundo da pista que queria treinar para poder escutar e tocar junto. Gostaria de deixar a pista com 10% do volume, por exemplo, citou o usuário.
Usuário 5 foi capaz de fazer o fluxo do aplicativo sem dificuldade. Relatou como positiva a experiência de uso do sistema mas também comentou que sentiu falta de uma opção de poder diminuir a velocidade de execução da música para poder treinar trechos mais complexos de uma música.
Usuário 6 teve dificuldade ao chegar na tela de status do aplicativo mas após explicação seguiu o fluxo. Gostou do play-along gerado e relatou que gostaria que tivesse a possibilidade de se gravar tocando.
6. Conclusões
Este trabalho permitiu construir um sistema automático de play-along, não encontrado até o momento pelas minhas pesquisas, e com um diferencial de ser também móvel, que cabe na palma da mão, através do smartphone. Mostrou que é possível contribuir no ramo da computação musical agregando técnicas existentes como Source Separation com temas pouco explorados como play-along.
Há muitos pontos a ser trabalhados devido a direitos autorais que podem dificultar a distribuição deste trabalho. Compartilhar ou distribuir os play-alongs gerados pode infringir direitos autorais dos artistas e do próprio Youtube que é usado no sistema.
Existe também um desafio arquitetural de como escalar os play-alongs gerados, uma vez que, o Youtube tem uma biblioteca muito vasta. Como registrar os play-alongs já gerados
32
de forma escalável sem afetar a velocidade e usabilidade do sistema? Como escalar o armazenamento dessas faixas?
6.1. Trabalhos Futuros
Feedbacks coletados nas entrevistas de validação se enquadram para futuros
aprimoramentos. Os relatos indicam que há muito trabalho futuro a ser feito nesse tema ainda, como explicado no relatos, além dos próprios desafios arquiteturais mencionados. Todas as dores dos usuários relatados na validação se enquadram em trabalhos futuros.
Outro ponto não trabalhado seria realizar testes de validações mais parametrizadas e com relevância estatística mais forte para avaliar melhor a usabilidade do aplicativo e a relevância dele no aprendizado musical.
7. Bibliografia
[1] Z. Rafii and A. Liutkus and F. R. Stöter and S. I. Mimilakis and D. FitzGerald and B.
Pardo, “An Overview of Lead and Accompaniment Separation in Music.” IEEE/ACM Transactions on Audio, Speech, and Language Processing vol 26, pp.1307-1335, 2018 [2] Romain Hennequin and Anis Khlif and Felix Voituret and Manuel Moussallam, “Spleeter:
a fast and efficient music source separation tool with pre-trained models.” The Open Journal vol 5, pp. 2154, 2020
[3] Monali R. Pimpale, Shanthi Therese , Vinayak Shinde, “A Survey on: Sound Source Separation Methods.” International Journal of Computer Engineering In Research Trends vol 3, pp. 580-584, 2016
33
