Show HN: We made a fast audio editor for podcasting(teapodo.com)
teapodo.com
Show HN: We made a fast audio editor for podcasting
https://teapodo.com/
65 comments
Thank you very much for the awesome feedback. The whole team is overjoyed. It gave us direction. The good news is that it pretty much matches our roadmap, and a lot of the features are already on the way. Again, we greatly appreciate your contribution.
The video one is something I use regularly with audacity so replacing it would be great for me (I record with OBS then drag it in to extract the audio because OBS has a great built in audio filter).
I did a podcast [1] and edited it myself, at first with Garage Band and then with Audacity. I used Audacity's package of audio processing. After learning the hot keys, I got reasonably proficient with it.
I'm not doing it anymore, but I'd be curious what suggestions you'd have.
(I have no idea what "ducking / side chain" means.)
[1] https://operationcode.org/podcast
I'm not doing it anymore, but I'd be curious what suggestions you'd have.
(I have no idea what "ducking / side chain" means.)
[1] https://operationcode.org/podcast
Ducking is just reducing the channel volume dynamically. For example when someone isn't speaking.
A Side Chain controls some effect on one channel based on the signal from a separate channel. Such as "ducking" background music when someone is talking.
A Side Chain controls some effect on one channel based on the signal from a separate channel. Such as "ducking" background music when someone is talking.
Ducking specifically refers to lowering the volume of one track based on peak levels in another track. One track "ducks" under the other. It's related to a side chain input on a compressor.
Dynamically lowering a quiet signal is done by an "expander", or a "gate" if it's lowered to zero.
Dynamically lowering a quiet signal is done by an "expander", or a "gate" if it's lowered to zero.
Listened for a few minutes: I'd tweak the EQ so that voices sound more pleasant. In fact the remote voice (is it Zoom or something similar?) sounds awful to be honest, but that's the shortcoming of this type of recordings. So you need to apply a different EQ to the remote voice: reduce the highs and slightly boost the mids/lows, but it may end up being tricker than that.
Ducking in general is an effect used a lot on radio: you have a background music that automatically "ducks" when there's a voice over it. In other words, background music gives way to the voice.
Ducking in general is an effect used a lot on radio: you have a background music that automatically "ducks" when there's a voice over it. In other words, background music gives way to the voice.
Thanks. It was Skype, actually.
twangist(1)
Fades are probably the most important, imo.
I can't test this because I don't have the latest or greatest Mac, but
what separates this from something like Reaper? From what I can tell this doesn't look anywhere near ready for production use. Reaper can do all of this on all platforms right now, even a RaspPi, for a $60 one time purchase. Teapodo has a pretty high bar to clear.
I didn't see mention of VST support, does it include any VST's or VST support? I noticed in the screenshot that there is a "background music" track; does it facilitate sidechain compression? I don't see any channel strip functionality for EQ, compression, etc... Noise reduction?
Does it have the facilities to meet desired RMS/LUFS targets?
I also note from the notes that you're limited to 44.1, which would potentially make integrating with a video podcast problematic.
I didn't see mention of VST support, does it include any VST's or VST support? I noticed in the screenshot that there is a "background music" track; does it facilitate sidechain compression? I don't see any channel strip functionality for EQ, compression, etc... Noise reduction?
Does it have the facilities to meet desired RMS/LUFS targets?
I also note from the notes that you're limited to 44.1, which would potentially make integrating with a video podcast problematic.
On a Mac, GarageBand does almost everything you might need.
I used to use Reaper, I was using it on a Mac back around V3, but the problem with Reaper is that it is general purpose and as someone else mentioned, that comes with a much steeper learning curve.
A podcast app is more like a video editor... you pull in audio from various sources, sync it up, add in some jingles and background/intro/outro music, paste in ads you pre recorded, and mixdown to an MP3 with chapters. It's not really the same requirements as something like Reaper.
I used to use Reaper, I was using it on a Mac back around V3, but the problem with Reaper is that it is general purpose and as someone else mentioned, that comes with a much steeper learning curve.
A podcast app is more like a video editor... you pull in audio from various sources, sync it up, add in some jingles and background/intro/outro music, paste in ads you pre recorded, and mixdown to an MP3 with chapters. It's not really the same requirements as something like Reaper.
Do you know about Ultraschall?
It is geared towards podcasting, based on Reaper. Works very well, though I have no experience in using other tools in the space.
https://github.com/stonerl/REAPER
It is geared towards podcasting, based on Reaper. Works very well, though I have no experience in using other tools in the space.
https://github.com/stonerl/REAPER
No, I haven't - I don't have a recent licence for Reaper (mine was for 2.x and therefore I only got 3.x without buying more and I started to use GarageBand as I was only doing light stuff by that point.) Sounds interesting though.
I used GB for a while, but I found Audacity much better. It's overkill for podcast editing, but it IS free.
Learning reaper takes time and is not easy. (and I have a reaper license and love it) If this provides a good tool that's easy to use and provides some podcast-specific features that audacity doesn't, I think there's market for it.
Reaper is awesome. But perhaps also not easy to get started with. A comparison to audacity seems more on point.
Yeah I agree this is a lot more like Audacity. But if it has chapter support and clips can be aligned like in something like a regular DAW, it has an advantage.
One feature that audio editing software really needs, if you're working with voice over or podcast audio, is a decent range of basic compression filters to apply. Whether it's just one person's voice or multiple people's, you need to shift the dynamic range of all the inputs into a sensible range, and with a sensible average loudness - just your basic management of levels. This is the first thing I look for, does teapodo have this?
Adobe Audition (not free) and Davinci Resolve's Fairlight (free, but obviously packaged with the rest of Resolve) have a bunch of filters, effects and even some helpful presets that make this straightforward.
Adobe Audition (not free) and Davinci Resolve's Fairlight (free, but obviously packaged with the rest of Resolve) have a bunch of filters, effects and even some helpful presets that make this straightforward.
To weigh in with an opposite opinion: if you make audio software, please, don't spend your time on reimplementing audio filters. It takes time and focus from things your program just has no way of doing with 3d party plugins. There's an over-abundance of audio processing plugins of various kinds and it's much easier just to support LV2 or VST (or, maybe, Clap, if you're optimistic about its future).
If you must bundle something, just add a JSFX interpreter and bundle a bunch of JSFX scripts. Your power users will thank you for it.
If you must bundle something, just add a JSFX interpreter and bundle a bunch of JSFX scripts. Your power users will thank you for it.
This is indeed a very interesting idea - taking advantage of the existing ecosystem. Like what the Language Server Protocol has done to the text editing world.
Thanks for the suggestion and we will definitely consider it.
Thanks for the suggestion and we will definitely consider it.
VST/AU plugin support is in our roadmap. So yeah, you bet that we will take advantage of the plugins ;-). In the meanwhile, you can use do further editing on top of Teapodo's output with other power tools.
Are the sessions by any chance stored as plain text files? What's the session format like?
I used Non DAW [1] quite a bit to edit radio shows, and I loved its session format: each and every editing step is written in the file as a single-line entry. As a result, the sessions were really fun to parse and modify with awk scripts. The "unlimited undo" feature was also just consecutive lines in the session file. Most importantly, I could write a stupid converter in awk to turn the .non files into Vegas EDL files (a plain text format). From there, I could use the fascinating AATranslator [2] to convert my sessions into Avid Pro Tools files, which my editing studio was using and insisted. Saved me a ton of trouble: no need to edit my show in WinXP, Pro Tools 7 (!) and its hopeless fan noise even during simple, almost idle-like editing tasks. I wonder if later Pro Tools versions are any better in terms of resource overconsumption; I always found that almost ridiculous.
As a frugal systems geek and a dreamer, I've been conceptualizing a text-based non-destructive audio editing suite written in awk. No GUI, just operating with text files and terminal, along the lines of Mixer4 (really cool conception, unfortunately closed source) [3], Ecasound [4] and SPED (I think this was just an academic conception, though) [5].
This is still just a dream, though. Non-destructive audio editing with basic Unix tools in an as-simple-as-possible ed-like interface.
1: https://non.tuxfamily.org
2: https://www.aatranslator.com.au/
3: http://www.acousticrefuge.com/mixer4.htm
4: https://ecasound.seul.org/ecasound/
5: https://tinyurl.com/y9s8mgme
I used Non DAW [1] quite a bit to edit radio shows, and I loved its session format: each and every editing step is written in the file as a single-line entry. As a result, the sessions were really fun to parse and modify with awk scripts. The "unlimited undo" feature was also just consecutive lines in the session file. Most importantly, I could write a stupid converter in awk to turn the .non files into Vegas EDL files (a plain text format). From there, I could use the fascinating AATranslator [2] to convert my sessions into Avid Pro Tools files, which my editing studio was using and insisted. Saved me a ton of trouble: no need to edit my show in WinXP, Pro Tools 7 (!) and its hopeless fan noise even during simple, almost idle-like editing tasks. I wonder if later Pro Tools versions are any better in terms of resource overconsumption; I always found that almost ridiculous.
As a frugal systems geek and a dreamer, I've been conceptualizing a text-based non-destructive audio editing suite written in awk. No GUI, just operating with text files and terminal, along the lines of Mixer4 (really cool conception, unfortunately closed source) [3], Ecasound [4] and SPED (I think this was just an academic conception, though) [5].
This is still just a dream, though. Non-destructive audio editing with basic Unix tools in an as-simple-as-possible ed-like interface.
1: https://non.tuxfamily.org
2: https://www.aatranslator.com.au/
3: http://www.acousticrefuge.com/mixer4.htm
4: https://ecasound.seul.org/ecasound/
5: https://tinyurl.com/y9s8mgme
I resonate with you as an Emacs user myself. The team think about audio editing a lot. Comparing it with text editing (vim, emacs, etc.). It gets philosophical at times. It is pretty hard to get it right. But we are still figuring it out. Thanks for your invaluable input.
Teapodo's project file is in JSON format and it is non-destructive editing (meaning to the source audio file). We also support undo/redo within a session.
Teapodo's project file is in JSON format and it is non-destructive editing (meaning to the source audio file). We also support undo/redo within a session.
I love the ID3 support:
ID3 Chapters
Finalizing your project by marking the project into Chapters.
When exported, Chapters are written as ID3 Chapter Frames in the audio file, which can then be picked up by supported audio players (such as Podcast players).
ID3 Chapters
Finalizing your project by marking the project into Chapters.
When exported, Chapters are written as ID3 Chapter Frames in the audio file, which can then be picked up by supported audio players (such as Podcast players).
"Perfect for podcasting" to me means that it has a built in compressor (or at least VST support). So many podcasts are two people talking where one is louder than the other.
hey OP, great project! I produce a daily mixtape (https://mixtape.swyx.io/) and Audacity's performance and small bugs bother me a lot so i'm in the market for a new editor.
i tried this out and first thing i looked for was a way to adjust sound levels in the clip (eg to fade in music for voice over, or crossfade clips). thats probably the only feature missing for me.
thank you!
i tried this out and first thing i looked for was a way to adjust sound levels in the clip (eg to fade in music for voice over, or crossfade clips). thats probably the only feature missing for me.
thank you!
Thank you for your feedback. I hear you. We are working on fade-in/fade-out and it's coming very soon.
My current workaround for the sound level of a clip is to move it to a new track and adjust the level of that track. I will talk to the boys back there about it.
My current workaround for the sound level of a clip is to move it to a new track and adjust the level of that track. I will talk to the boys back there about it.
pls let me know when it ships and i'd be happy to try it out again!
This looks great if you need multi-track, but if you don't, another app I highly recommend is Rougue Amoeba's Fission. It's quick and simple, and it edits audio losslessly wherever possible.
I actually really wish I had something similar for video...
I actually really wish I had something similar for video...
> I actually really wish I had something similar for video...
Try this: https://github.com/mifi/lossless-cut
I am using the binary on macOS. The UI is a bit idiosyncratic but it works quite well and is ideal to cut a video down to the essential parts without loss of quality.
Try this: https://github.com/mifi/lossless-cut
I am using the binary on macOS. The UI is a bit idiosyncratic but it works quite well and is ideal to cut a video down to the essential parts without loss of quality.
avidemux can do some limited editing losslessly. Most notably is that for a lot of formats, cut points will be snapped to the nearest keyframe
multi-track is actually great, since if one speaker makes some noise while the other is talking, you can just silence it.
So the GUI is in Qt and the internal engine in Rust. Do you call Rust code from cpp? It's less common in that direction, how was your experience doing it? any obvious traps?
Hello there, Yan from Teapodo here.
Yes, we structured our application around C++, and the Rust part is more of an internal library called from C++ via FFI.
We took this approach initially because I had done this before in another application[1], and I was quite happy about the result then.
Also, as we are a very small team (2 developers) developing a cross-platform application, we thought it makes sense to only use Rust to solve the hardest part first (i.e. the audio engine) and offload other complexities (e.g. a cross-platform GUI, reactive data binding, etc.) to some existing frameworks (Qt in this case), so that we are less likely to be overwhelmed.
We did end up with writing the whole application's data flow in Rust as well (e.g. the whole application state tree, the undo/redo, and all of the business rules such as audio clip size constraints, etc.). We did it because we thought it's also a pretty isolated problem, so the whole thing can be easily encapsulated in pure Rust without interacting to much with other systems.
Our experience of doing it this way was pretty good. We basically live in two worlds: the core Rust library and the GUI (in fact they are even separate Git repositories). We follow best practices in each worlds, and they interact with each other using FFI (in C).
The only negative side of this for us so far is that there are some manual steps involved when crossing the FFI boundary (on either directions), for example: - When providing a functionality from the Rust library to the UI, we need to write an unsafe C ABI binding for each API we want to expose - On the other direction, if we want to pass complex data structures from the UI to the Rust library, we would need to either interpret the data using C primitives or create an opaque type and require the UI to properly initialize the data
I believe there might be ways to make it more ergonomic (e.g. procedural macros, or some existing crates such as cxx), and we will certainly look into improving it at some point!
---
[1]: I built a Unicode tool for macOS and iOS, with the UI being written in AppKit and UIKit, and the Unicode data being provided by Rust.
Yes, we structured our application around C++, and the Rust part is more of an internal library called from C++ via FFI.
We took this approach initially because I had done this before in another application[1], and I was quite happy about the result then.
Also, as we are a very small team (2 developers) developing a cross-platform application, we thought it makes sense to only use Rust to solve the hardest part first (i.e. the audio engine) and offload other complexities (e.g. a cross-platform GUI, reactive data binding, etc.) to some existing frameworks (Qt in this case), so that we are less likely to be overwhelmed.
We did end up with writing the whole application's data flow in Rust as well (e.g. the whole application state tree, the undo/redo, and all of the business rules such as audio clip size constraints, etc.). We did it because we thought it's also a pretty isolated problem, so the whole thing can be easily encapsulated in pure Rust without interacting to much with other systems.
Our experience of doing it this way was pretty good. We basically live in two worlds: the core Rust library and the GUI (in fact they are even separate Git repositories). We follow best practices in each worlds, and they interact with each other using FFI (in C).
The only negative side of this for us so far is that there are some manual steps involved when crossing the FFI boundary (on either directions), for example: - When providing a functionality from the Rust library to the UI, we need to write an unsafe C ABI binding for each API we want to expose - On the other direction, if we want to pass complex data structures from the UI to the Rust library, we would need to either interpret the data using C primitives or create an opaque type and require the UI to properly initialize the data
I believe there might be ways to make it more ergonomic (e.g. procedural macros, or some existing crates such as cxx), and we will certainly look into improving it at some point!
---
[1]: I built a Unicode tool for macOS and iOS, with the UI being written in AppKit and UIKit, and the Unicode data being provided by Rust.
Thanks for your detailed answer. That's sound really interesting. Maybe you can try your luck for "This week in Rust"[0].
[0] -- https://github.com/rust-lang/this-week-in-rust
[0] -- https://github.com/rust-lang/this-week-in-rust
Aha, that sounds like a neat idea! Thanks for the suggestion!
I'm reasonably happy with qmetaobject crate of rust to write gui in qml. All logic in rust, all presentation qml
Really needs plugin support (if it's there, I don't see it). Plugins can make an otherwise minimal editor viable.
For example: compression, normalization, and ducking seem to be missing, and I wouldn't want to edit speech without them.
For example: compression, normalization, and ducking seem to be missing, and I wouldn't want to edit speech without them.
Automatic speech recognition for search and redaction too.
Back when I was hosting and editing several weekly podcast I was in love with a now-defunct app [Ubercaster](https://www.provideocoalition.com/uebercaster_the_most_compl...).
That thing was incredible, and I wish they were able to keep developing it. The only recording and editing suite that felt like it was designed and built by people who actually made reasonably complex podcasts regularly.
I'm really interested to see if Teapodo can grow to be like that!
That thing was incredible, and I wish they were able to keep developing it. The only recording and editing suite that felt like it was designed and built by people who actually made reasonably complex podcasts regularly.
I'm really interested to see if Teapodo can grow to be like that!
What are you using now? Have you tried other podcast-focused editors like Descript, Hindenburg, or Reaper with Ultraschall?
I haven't done regular podcasting in a long time - I recently made a ~40 minute audio program for internal distribution at work and edited it in GarageBand. While it did a pretty decent job and resulted in something that sounded pretty professional, it definitely felt clunky editing and mixing four channels of microphone audio. Descript looks VERY cool!
I definitely like the UI, speed, and the simplicity.
The two things that will prevent me from actually using it for my pods are the much discussed VST support and the lack of ability to select a range and mute the selection. The second is actually more important, because it allows for small audio imperfections, like a cough, um, or smack, to be removed from the recording without requiring a split -> truncate workflow that breaks the recording into two pieces, which then have to be moved and repositioned separately.
The two things that will prevent me from actually using it for my pods are the much discussed VST support and the lack of ability to select a range and mute the selection. The second is actually more important, because it allows for small audio imperfections, like a cough, um, or smack, to be removed from the recording without requiring a split -> truncate workflow that breaks the recording into two pieces, which then have to be moved and repositioned separately.
The VST support is on our roadmap and it's coming fast!
Currently how I remove noise is to cut it out. Yes, it breaks it into multiple clips, but we have features like "Select All from playhead" and "Select All Clips on Track" to make operating on multiple clips easy. Oh, we also have marquee selection support.
Thank you very much for your feedback. I will talk to the guys about the feature.
Currently how I remove noise is to cut it out. Yes, it breaks it into multiple clips, but we have features like "Select All from playhead" and "Select All Clips on Track" to make operating on multiple clips easy. Oh, we also have marquee selection support.
Thank you very much for your feedback. I will talk to the guys about the feature.
This is pretty cool. It seems really aimed at one use case which most audio editors don't do. The interface looks slick.
I can't easily test it now, but since it's not listed, I suspect limiter / compressor / noise suppression is not implemented? Those 3 would likely be the filters people expect the most for voice recording. (maybe also deesser)
Also I believe Audacity is planning to do non-linear editing soon, so it may take over a lot of that use case.
I can't easily test it now, but since it's not listed, I suspect limiter / compressor / noise suppression is not implemented? Those 3 would likely be the filters people expect the most for voice recording. (maybe also deesser)
Also I believe Audacity is planning to do non-linear editing soon, so it may take over a lot of that use case.
Thanks! Yup, noise gate / compressor / limiter / EQ are on our roadmap, hopefully we will be able to release them soon!
it says it uses Qt6 with rust, is it Qt6/c++ calling rust, or rust calling c++?
This ui looks awesome, but where can I find code samples of mixing Qt6 and rust?
This ui looks awesome, but where can I find code samples of mixing Qt6 and rust?
You mean qt6 and rust in your last sentence i think.
Not on a computer right now but qml <-> rust is reasonably mature. Will post later
Not on a computer right now but qml <-> rust is reasonably mature. Will post later
when i download the release, chrome gives me a nasty releasxe that Teapodo...zip is not commonly downloaded and may be dangerous.
It may be, may not be. Either way, I'm not opening on my work mac. Do you have a release for Linux, since it's written in rust?
Also, I think if you make it a .app with a developer license from apple, the creepy message goes away.
It may be, may not be. Either way, I'm not opening on my work mac. Do you have a release for Linux, since it's written in rust?
Also, I think if you make it a .app with a developer license from apple, the creepy message goes away.
Thanks for the heads up, we will look into this.
Re: Linux support, it's on our radar, and I believe the code base is Linux compatible, so stay tuned!
Re: Linux support, it's on our radar, and I believe the code base is Linux compatible, so stay tuned!
I use Hindenburg Pro to edit my podcasts currently. What will your software do better than Hindenburg?
Features that I think are critical for striking the minimalism/utility balance for podcast editing:
- Enveloping per clip, i.e. fade in - fade out
- Support AU plugins (at least the system ones) - this alone will add EQ, compression and other effects, so quite important
- Ducking / side chain
- Option to embed all imported audios so that I can move my projects around
- Import a video file but use only the audio track
- Put time markers and name them
- Go to time or marker
- Loop between two markers
- iPad version?
These are just off the top of my head.
Kudos to you guys and good luck with the project!