DEV Community: Thiago Machado

Como Criei Meu Próprio Sistema de Transcrição de Áudio

Thiago Machado — Mon, 04 Aug 2025 03:02:16 +0000

Motivação

Se você, como eu, já recebeu áudios intermináveis no Telegram, sabe o quanto pode ser cansativo ouvir tudo — especialmente quando a função de transcrição oficial é paga e exige assinatura anual. Decidi que não queria depender de serviços pagos para algo tão simples. E mais: queria integrar a solução ao meu bot multi-agent do Telegram, tornando a experiência ainda mais prática e automatizada.

O Problema

Áudios do Telegram são cada vez mais comuns, mas a transcrição automática é um recurso restrito a assinantes.
Ouvir áudios consome tempo e energia, principalmente em grupos ou canais profissionais.
Soluções existentes são fechadas, pagas ou pouco flexíveis para integração com bots customizados.

A Solução: Um Sistema de Transcrição Agnóstico e Extensível

Desenvolvi um sistema open source, com arquitetura hexagonal e Domain-Driven Design (DDD), capaz de integrar múltiplos provedores de IA (OpenAI, Gemini, etc.) sem acoplamento direto. O sistema é modular, testável e pronto para ser usado em qualquer projeto Python — inclusive bots do Telegram!

Principais Características

Agnóstico a provedores de IA: Você pode usar OpenAI, Gemini, ou adicionar qualquer outro backend facilmente.
Extensível: Basta implementar a interface Transcriber para adicionar novos provedores.
Fallback automático: Se um provedor falhar, o sistema tenta o próximo da lista.
Configuração flexível: Permite definir idioma, timeout, número de tentativas e opções específicas por provedor.
Testes automatizados: Cobertura completa para garantir robustez.
Pronto para bots: Basta importar o pacote e integrar ao seu bot multi-agent.

Como Funciona

Recebe o áudio do Telegram (ou de qualquer fonte).
Cria uma tarefa de transcrição (TranscriptionJob) com o arquivo recebido.
Define um plano de transcrição (TranscriptionPlan) com provedores e políticas de fallback.
Executa o caso de uso (ExecuteTranscriptionPlan), que orquestra a transcrição e retorna o texto.
Entrega o resultado para o usuário, sem precisar ouvir o áudio!

O Que Aprendi

Arquitetura hexagonal realmente facilita a manutenção e extensão do sistema.
Domain-Driven Design ajuda a separar regras de negócio de detalhes técnicos.
Fallback inteligente é essencial para garantir robustez em sistemas que dependem de APIs externas.
Open source é liberdade: agora qualquer pessoa pode usar, adaptar e contribuir.
Bots multi-agent podem ser muito mais úteis quando integrados a sistemas abertos e flexíveis.

Resultado Final

Nunca mais precisei ouvir áudios do Telegram — tudo é transcrito automaticamente!
Não pago assinatura anual para um recurso simples.
O sistema está disponível para qualquer pessoa usar, adaptar ou integrar em seus próprios projetos.
Aprendi muito sobre arquitetura, testes e integração de IA.

Como Usar

Clone o repositório: git clone https://github.com/dublado/audio-transcriber.git
Instale as dependências: pdm install -G dev
Execute o exemplo: python examples/simple_usage.py
Integre ao seu bot multi-agent do Telegram!

Próximo Desafio: Otimização de Custo e Velocidade

O próximo passo para evoluir o sistema será adicionar um filtro de otimização, acelerando o áudio antes de enviar para transcrição. A ideia é inspirada no artigo OpenAI Charges by the Minute, So Make the Minutes Shorter, onde acelerar o áudio pode reduzir o tempo (e custo) de processamento, sem perder a inteligibilidade para os modelos de IA.

Por que acelerar?
- Provedores como OpenAI cobram por minuto de áudio processado.
- Áudios acelerados podem ser transcritos mais rápido e com menor custo.
- O filtro pode ser ajustado para manter a clareza da fala, mesmo em velocidades maiores.
Desafio extra: Será que isso funcionaria com vídeos? 😄

Essa otimização pode ser integrada como uma etapa opcional no pipeline, tornando o sistema ainda mais eficiente e econômico para quem recebe muitos áudios (ou vídeos) diariamente.

Se gostou do projeto, contribua ou compartilhe! Nunca mais ouça áudios — apenas leia!

Solução para Problema de Glitch Gráfico Nvidia GPU

Thiago Machado — Sat, 29 Mar 2025 22:01:30 +0000

Recentemente, me deparei com um problema gráfico no Visual Studio Code(e variantes) que afetava a interface do programa. A distorção acontecia de forma aleatória, e a cada vez que eu alternava entre janelas, digitava, ou até mesmo passava o mouse sobre alguns campos. Após algumas tentativas de resolver, finalmente encontrei uma solução que pode ser útil para quem passar por um problema semelhante.

Descrição do Problema

O erro gráfico apareceu da seguinte maneira:

A distorção ocorria sem ação explícita minha, aparecendo quando eu mudava de tela, digitava, ou até mesmo apenas passava o mouse sobre a interface.
Em alguns casos, a distorção não afetava os campos de texto, mas aparecia ao redor desses campos.
O problema persistia, mesmo depois de tentar reinstalar o Visual Studio Code e remover as extensões.

Tentativas de Solução

Antes de encontrar a solução, tentei algumas abordagens:

Reinstalar o Visual Studio Code: A reinstalação do programa não teve efeito sobre o problema.
Desabilitar Extensões: Tentei remover todas as extensões, mas isso não fez diferença.
Configuração de Argumentos de Execução: Segui algumas sugestões e tentei adicionar o argumento "disable-hardware-acceleration": true nas configurações do VS Code, mas isso também não resolveu o problema.

A Solução Encontrada

Foi ao investigar mais a fundo as configurações gráficas do sistema que encontrei a verdadeira causa do problema. Percebi que o erro estava relacionado ao "Image Sharpening" no painel de controle da Nvidia. Aqui estão os passos que segui para corrigir:

Abrir o Painel de Controle da Nvidia: Deve estar instalado no seu SO.
Ajustar Configurações 3D: Naveguei até as configurações 3D.
Desabilitar o Aprimoramento de Imagem: Procure "Image Sharpening" ou o relativo em português, desativei a opção.

IDE - plus

Após desabilitar a opção no painel de controle da Nvidia, o problema foi resolvido. Essa solução pode ser útil para quem estiver enfrentando erros gráficos semelhantes no Visual Studio Code. Caso você também enfrente esse erro, recomendo tentar essa abordagem ou, se necessário, adicionar o argumento "disable-hardware-acceleration": true para forçar a utilização de renderização via software, direto na configuraçao de argumentos.

(Ctrl+Shift+P). Pesquise por Configure Runtime Arguments command.

Com isso, reinicie a IDE e ficou tudo normal novamente

Da mudança do Redis surge o Valkey defendendo o Open Source

Thiago Machado — Sat, 13 Apr 2024 23:53:43 +0000

Recentemente, o Redis, um dos principais provedores de soluções de armazenamento de dados em memória e broker, anunciou uma mudança significativa em sua abordagem de licenciamento. Migrando da Licença BSD de 3 Cláusulas(3-Clause BSD) para um modelo de licença dupla, oferece agora a Redis Source Available License versão 2 (RSALv2) ou a Server-Side Public License versão 1 (SSPLv1).

Essa decisão causa ressonância na comunidade de desenvolvedores, lembrando a transição do MySQL para o MariaDB após a aquisição do MySQL pela Oracle.

Do que se tratam as licenças ?

A RSALv2 restringe a oferta de serviços gerenciados sem compartilhar modificações, impedindo grandes corporações de usar o software sem contribuir de volta. A SSPLv1, mais restritiva, exige que serviços que usam o software e são oferecidos ao público compartilhem o código-fonte completo, promovendo um ecossistema de software livre mais robusto e transparente. Ambas visam proteger o investimento comunitário e incentivar a colaboração.

Aquisições Históricas: MySQL e MariaDB

A história do MySQL e do MariaDB é um exemplo emblemático de como uma comunidade pode responder a mudanças corporativas que poderiam limitar a liberdade de um software open source. Quando a Oracle adquiriu o MySQL, havia uma preocupação legítima de que a nova gestão pudesse restringir o desenvolvimento open source da plataforma. Em resposta, a comunidade, liderada por um dos fundadores originais do MySQL, Michael "Monty" Widenius, iniciou o projeto MariaDB como um fork do MySQL.

Licenças do MySQL

O MySQL usa uma abordagem de licenciamento dual, dependendo do uso que será feito do software:

GNU General Public License (GPL) versão 2: Para a maioria dos usuários, o MySQL é disponibilizado sob a GPL versão 2. Esta é uma licença de software livre que permite que os usuários modifiquem e compartilhem o software, desde que suas modificações e software derivado também sejam distribuídos sob a GPL. O uso sob a GPL é adequado quando o MySQL é usado em aplicações também licenciadas de maneira compatível com a GPL, ou quando não se necessita de distribuição do software modificado.
Licença Comercial: Para empresas que não querem liberar o código-fonte de suas aplicações que incorporam MySQL ou que usam MySQL de maneira que não seja compatível com a GPL, a Oracle (que adquiriu o MySQL em 2010) oferece uma licença comercial. Isso permite o uso do MySQL em aplicações proprietárias.

Licenças do MariaDB

O MariaDB, por outro lado, é oferecido sob a GPL versão 2, mas com a garantia de que continuará sendo oferecido sob uma licença de software livre:

GNU General Public License (GPL) versão 2: A fundação MariaDB garante que todas as versões do MariaDB permaneçam livres e abertas sob a GPL versão 2. Isso assegura que, ao contrário do MySQL, não haverá uma opção de licença comercial que restrinja como o código pode ser usado ou modificado. O MariaDB é, portanto, mais alinhado com os princípios tradicionais do software livre/open source em comparação ao MySQL pós-aquisição pela Oracle.

Essas diferenças refletem as distintas filosofias por trás de cada projeto: enquanto o MySQL pode ser usado em aplicações proprietárias sob sua licença comercial, o MariaDB se mantém estritamente dentro dos limites do open source sob a GPL.

Sistema	Licença	Categoria	Descrição
Redis	RSALv2, SSPLv1	Restricted	Restrições para uso em serviços gerenciados e exigência de compartilhamento de código em certos contextos, menos permissiva para uso comercial.
MySQL	GPL v2, Licença Comercial	Restricted	GPL v2 permite uso aberto mas com restrições de compatibilidade, Licença Comercial necessária para aplicações proprietárias.
Valkey	BSD 3-Clause	Open Source	Muito permissiva, permite uso e modificação sem restrições significativas.
MariaDB	GPL v2	Open Source	Permissiva dentro dos padrões open source, exige que alterações e distribuições permaneçam open source, mas sem restrições comerciais adicionais.

Melhorias e Continuidade Open Source

MariaDB continuou a evoluir, ouvindo e se alinhando com as expectativas da comunidade open source:

Desenvolvimento Ativo: MariaDB tem recebido atualizações regulares que introduzem novas funcionalidades, mantendo-se sempre à frente das necessidades dos desenvolvedores.
Compatibilidade com MySQL: Inicialmente, MariaDB foi feito para ser totalmente compatível com MySQL, garantindo que os usuários pudessem mudar de um sistema para outro sem problemas.
Inovações: MariaDB introduziu várias inovações, incluindo motores de armazenamento avançados como Aria e TokuDB, que oferecem melhor desempenho e funcionalidades.

MySQL, sob gestão da Oracle, também continuou a desenvolver-se, garantindo que a tecnologia não fosse eclipsada pela sua contraparte open source:

Melhoria na Performance: As versões recentes de MySQL oferecem melhorias significativas no desempenho e na segurança.
Funcionalidades Empresariais: Incorporação de características orientadas para o empresariado, como a replicação baseada em grupo e melhorias na segurança. Ambos os projetos têm prosperado, garantindo que a tecnologia MySQL original mantenha-se relevante e útil, tanto em formas open source como em variantes comerciais.

A Reação da Comunidade

Valkey é visto como um Farol de Esperança em resposta à mudança do Redis, liderado pela Linux Foundation com apoio de grandes empresas como a Amazon e a Google.

As mudanças nas licenças do Redis e o surgimento de projetos como Valkey são lembretes vitais de que o ecossistema de software é dinâmico e requer uma vigilância constante. Como engenheiro que acompanhou várias transições no mundo do open source, vejo esses movimentos como essenciais para o equilíbrio entre inovação aberta e o direito de os criadores e colaboradores serem justamente recompensados. Nesse caso, pelo histórico, todos ganham.

A história nos mostra que a comunidade de código aberto é resiliente e adaptativa. Projetos como o Valkey não são apenas respostas a mudanças imediatas, mas também um investimento no futuro da tecnologia open source, garantindo que ela permaneça sustentável, inclusiva e inovadora. Como a evolução do MySQL para o MariaDB, ou a aquisição positiva da Java pela Sun Microsystems, a trajetória do Redis pode muito bem ser um catalisador para novas ideias e melhores práticas em open source.

Alternativas

Apache Cassandra [https://cassandra.apache.org]
Amazon DynamoDB [https://aws.amazon.com/pt/dynamodb/]
Apache Ignite [https://ignite.apache.org/]
Azure Cosmo DB[https://azure.microsoft.com]
Dragonfly [https://www.dragonflydb.io/redis-alternative]
KeyDB [https://docs.keydb.dev/]
Memcached [https://memcached.org/]
Valkey [https://valkey.io]

Referências

Valkey - Linux Foundation Launches Open Source Community [https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community]
Valkey - Github [https://github.com/valkey-io/valkey]
Anúncio oficial do Redis [https://redis.io/blog/what-redis-license-change-means-for-our-managed-service-providers/]
Docker hub(UNSTABLE) [https://hub.docker.com/r/valkey/valkey]
Licença RSALv2 [https://redis.io/legal/rsalv2-agreement/]
Licença SSPLv1 [https://redis.io/legal/server-side-public-license-sspl/]
Why AWS, Google and Oracle are backing the Valkey Redis fork [https://techcrunch.com/2024/03/31/why-aws-google-and-oracle-are-backing-the-valkey-redis-fork/]
Redis is no longer open source as of yesterday [https://www.reddit.com/r/selfhosted/comments/1bkhky1/fyi_redis_is_no_longer_open_source_as_of_yesterday/]
MySQL-MariaDB history talk [https://mariadb.org/wp-content/uploads/2019/11/MySQL-MariaDB-story.pdf]
Acquisition of Sun Microsystems by Oracle [https://en.wikipedia.org/wiki/Acquisition_of_Sun_Microsystems_by_Oracle_Corporation]

Monolito, Microserviços, não necessariamente uma jornada evolutiva

Thiago Machado — Fri, 15 Mar 2024 11:59:39 +0000

Conversando em um coletivo de amigos, emergiu uma perspectiva pragmática que comenta essa jornada de desenvolvimento de software.

No desenvolvimento de software, profissionais debatem se iniciar com um monolito ou microsserviços, impactando complexidade, custos e agilidade. Uma visão pragmática recomenda uma jornada de desenvolvimento evolutiva.

O Ponto de Partida: Monolito

O consenso geral favorece começar o desenvolvimento com uma arquitetura monolítica, devido à sua simplicidade, custo inicial mais baixo e facilidade de manutenção. Um monolito integra todos os componentes do software, facilitando testes e desenvolvimento, o que é ideal para startups e projetos nas fases iniciais.

A Transição: De Monolito para Microsserviços

Conforme a aplicação expande em usuários, funcionalidades ou equipe, as restrições do monolito surgem, sugerindo a mudança para microsserviços, que promovem escalabilidade e desenvolvimento modular independente, facilitando a gestão de grandes equipes e necessidades de escalabilidade.

Observamos alguns pontos de restrição:

Escalabilidade Limitada
Acoplamento Forte
Tempo de Implantação Prolongado
Dificuldade na implementação de novas tecnologias
Comlpexidade do código
Limitação na Disponibilidade
Desafios na escalabilidade do time
Testes complicados
Problemas de desempenho
Gerenciamento de dependencias
Atualizações de segurança podem ser uma dor de cabeça

A Decisão por Microsserviços: Quando e Por quê?

A transição para microsserviços deve ser motivada por necessidades específicas, como escalabilidade e trabalho de múltiplas equipes em diferentes seções do projeto, que um monolito não atende bem. É crucial considerar os custos extras e a complexidade adicional em infraestrutura e manutenção.

Práticas para uma Transição Suave

Uso de Containers: Adote Docker e Kubernetes para desenvolver, testar e implantar partes da aplicação de forma independente, alinhando a operação do monolito à dos microsserviços.

APIs Restful: Utilize APIs Restful para separação lógica e comunicação entre partes do sistema, facilitando a adaptação para serviços distintos.

Separação de Dados: Organize o banco de dados por serviço para minimizar o acoplamento e facilitar a migração para microsserviços.

Design Orientado ao Domínio: Aplique princípios de DDD para organizar o código modularmente e definir limites para futuros serviços.

Comunicação Baseada em Eventos: Integre filas e mensageria para uma comunicação assíncrona e desacoplada, preparando para a arquitetura de microsserviços e facilitando a transição com um acoplamento frouxo.

O Veredicto: Uma Abordagem Evolutiva

A abordagem evolutiva é ideal na arquitetura de software. Começar com um monolito ajuda startups e projetos iniciais a serem ágeis e a minimizar custos. Com o crescimento, pode-se considerar a mudança para microsserviços conforme as necessidades específicas, mas se atenha à necessidade do resultando, não à satisfações pessoais ou do time. Muito cuidado com o Hype, um bom meio de provar os Hypes e satisfazer a necessidade do time é aplicar pocs baseados nos interesses pessoais do time, é um bom meio de reciclar energia e motivar.

Para desenvolvedores experientes, preparar o terreno para essa possível transição, mesmo enquanto trabalham em um monolito, é uma estratégia astuta. Isso não apenas facilita uma futura migração para microsserviços, como também instila boas práticas de desenvolvimento desde o início.