Audacity 3.0
audacityteam.org
audacityteam.org
Audacity may had some quirks over the years but it's still one of the most (if not the most) accessible tool for audio editing by non-professionals with an adequate feature set. It's used by community radio stations all over the world since it's easy to teach and cross-platform while being free.
But hey, UI is hard and audio processing UIs are probably harder than most.
It's not pretty and looks cluttered, but those are just looks. Those aside, it's probably perfectly serviceable for getting work done. I like UIs where everything is just there (or even where you put it), and you don't need to dig in submenus that may even make you wait for animations. You can build effective muscle memory for this. It also appears it will let you make use of multiple monitors easily.
It just doesn't look great because font sizes and spacing is really inconsistent across types of UI elements: buttons get lots of space to breathe with big paddings and margins for some reason, any bar has very little space and gets a tiny font, lists have fonts way larger than everything else, ...
SoundForge was fantastic. Now I just do everything in Reaper. Both non-free of course, but Reaper is really cheap and works everywhere and does so much more than just audio editing.
Edit: the love Audacity is getting in the comments inspires respect! There is obviously something that I missed...
To give a concrete example: suppose I want to apply noise cancellation (something very few free audio tools provide I must add, and a really cool feature of Audacity):
- You select your track
- You go in Effect, you skim through the long (alphabetized) list to find "Noise reduction"
- You realize that you forgot to generate your noise profile, so you close the pop up because you can't reselect when the pop up is active
- You select your noise reference
- You return to Effect, skim through the long (alphabetized) list again, find noise reduction again
- You tell it to use the selected audio as noise reference.
- You close the window
- You select the entire audio again
- You return to Effect, skim through the long (alphabetized) list again, find noise reduction again
- You can tweak the various reduction parameters, then you can click "preview" again which pops a 2nd window up with a rudimentary audio player that doesn't let you do anything besides listening to the selected audio from the start. You can't focus on a particular zone or anything. If you want to do that you have to apply the noise reduction, close the module, return to the main window, listen to your track on the proper timeline then undo the reduction and return to Effects, skim through the long (alphabetized) list etc...
If there's a better way to do any of this I haven't found it.
I don't want to really to be too hard on Audacity, I'm genuinely thankful for its existence, but it's not a good example of UI done right IMO.
I like minimalism in UI, but I think it works best when it's flexible and composable (like Vim commands for instance). Audacity UI's is neither, it's just a long series of ad-hoc modules.
TBF default groupings are often based on the function baked into a VST/AU by the designer, and some of those groupings are more useful than others.
But given that Audacity's plugins are largely homebrewed, I don't there's a good reason not to get this right.
I find these kinds of problems baffling. And it's not that they're exclusive to open source, because they really aren't. (I'm looking at you, Adobe...)
Some designers just don't seem to get UI concepts like making common workflows as streamlined and effortless as possible, minimising clicks and scrolling, efficient presentation of options with useful grouping, and watching non-dev users interacting with the software to find out what feels clunky and excessively complex to them.
Not rocket surgery, but a very deep UI redesign compared to a dialog box.
I blame the traditional prevalence of highly self-contained plugins and little scripts (for example, Audacity has Nyquist scripts) that entail generic host applications that only really care about the subset of features that cannot be delegated to plugins (for example, Audacity has the waveform view).
I'm super interested in the UI design of really complex applications (like Audacity, or Photoshop, etc.). I would adore some kind of writeup on y'all's design process whenever you towards the end!
(Obviously a big ask for someone already doing a bunch of work for free, pls feel free to ignore me; just saying that I'd be interested :D)
Having actually used Audacity and Photoshop, I'd love to learn a bit more about how those design decisions were made.
The only thing I think I can remember clearly however was the question about the biggest regret which I think was one particular core datastructure that was an array but which they later wished they had used a linked list for instead.
Designing the Win95: https://socket3.wordpress.com/2018/02/03/designing-windows-9...
Also the final design guides: https://www.ics.uci.edu/~kobsa/courses/ICS104/course-notes/M...
A (really old) book: https://www.amazon.com/About-Face-Essentials-Interaction-Des...
Another book: https://www.amazon.com/Designing-Interfaces-Patterns-Effecti...
Oddly enough these are all ancient. There hasn't been much innovation in that space though. (apart from High Dpi and Dark Mode)
Blender recently did a redesign of their UI, they have lot's of discussions about their rationale.
Computers used to show light characters on a dark background. 8-bit platforms often defaulted to white text on a dark-blue background, which until just a few years ago was still available in Word as a checkbox option.
Then the "desktop publishing" craze came along, and brought the analogy of a computer screen to a piece of paper. But this inverse (black text on a white background) scheme ignored the fact that paper doesn't EMIT light. Using these systems was akin to reading the label on the surface of a lit light bulb all day.
But for two decades, Windows let you set up a system-wide color scheme whose colors would be inherited by (nearly) all applications. It was great; you could (and I did, in the early '90s) replace the dumb inverse default color scheme with a "charcoal" scheme... essentially exactly what most "dark modes" are today.
I think Unix GUIs allowed you to set up color schemes too, leaving only the vaunted Mac GUI as the hard-coded,glaring eyeball-strainer of the era.
But now that people are finally realizing that inverse color schemes suck, what did Microsoft do? REMOVE the color-scheme editor from Windows. So now we're being dribbled out "dark mode" one OS, Web page, and application at a time. And it's still hard-coded.
That's not innovation. It's pathetic.
>paper doesn't EMIT light
Your retina doesn't care if the photons it receives are emitted (as with CRTs) or reflected (as with paper). If you feel like you're staring into a lightbulb, your monitor's brightness is set too high. Set it properly, and, in a well lit environment, your monitor's white should match that of the wall behind it, or that of a piece of paper on your desk.
Or you get ancient looking Ui
Or you get platform spesific stuff!
Actually Java applications are kinda reasonable compromise
As are .NET applications. Yeah, most .NET desktop apps in the wild are technically chock full of Windowsisms, I've found that said apps more often than not Just Work(TM) on e.g. Linux w/ Mono, and alternative toolkits like Avalonia help further.
I'm hoping this is something that improved in 3.0.0, because using Audacity is becoming increasingly impractical. I was just trying to listen to 10 tracks one by one yesterday and even just muting/soloing a track would take about a second; it was horrible. Shrinking the window helps, but it's silly to have a tiny window and scroll around when you have a 4K display.
I kind of suspect this to be a windowing toolkit issue, and originally I thought it was macOS-specific (since I first noticed when I tried to recommend it to friends who use that), but ever since I moved to a 4K screen on Linux I noticed it's bad here too...
The Mac story is here: https://forum.audacityteam.org/viewtopic.php?f=47&t=111105
The workaround is, well, not using HiDPI mode which is silly. But Audacity doesn't even seem to support HiDPI mode on Linux properly to begin with (the entire UI is small), so that's not it per se... I guess wxGTK just struggles when it has to draw 4x as many pixels?
Apparently it's bad on Windows too: https://forum.audacityteam.org/viewtopic.php?t=111857
This is because the state machine that drives the draw context is synchronous. Every line, pixels (or anything, really) takes some CPU cycles.
Newer toolkits (QtQuick2, GTK4, Skia-based-ones) are hardware accelerated. They are slower of standard DPI, but much faster on HiDPI.
So, yes, they cannot be as snappy on HiDPI, the number of pixel gets bottlenecked by the single thread performance of the CPU. Those barely grow year-over-year, while the number of pixel went up a cliff overnight.
I've noticed that the Audacity issue seems proportional to the number of tracks (not how much of the screen they take up) and improves when I zoom in a lot (to the sample level), which tells me this isn't a simple pixel pushing problem but rather something more profound in Audacity. There is obviously something horribly inefficient about how waveforms are being drawn at lower zoom levels.
For comparison, I can run full-screen Ardour with an order of magnitude more tracks and complexity than Audacity and it still performs much better, even if it isn't perfectly smooth.
> which tells me this isn't a simple pixel pushing problem but rather something more profound in Audacity.
That's probably because of the cursor animation (when you play). Audacity has to redraw the entire track widget each time the needle moves unless they implement special double buffering + special damage area slices. By default, Qt/GTK/wx are too dumb to understand layers properly. They will redraw the entire rectangle if you try to stack things with any transparency or non-rectangle clips. Even with proper double buffering, combining both frame buffers is still done on the CPU. That's 2x4x{width}x{height}x{fps} bytes up load to the GPU per second. for a 4k ARGB8888 video frame @ 60fps, that's like 4GB/s of raw transfer if you rasterize each frames in the CPU.
(disclaimer: former KDE dev)
edit: If you run KWin, you can enable the redraw compositor plugin and see for yourself which area of the window are repainted.
Yes, it's poor UI.
It's a potential project killer, but it can be done. The trick is to wrap all your objects in QObject classes. You keep the old UI code as-is as long as possible.
The first Jedi mind trick is to reverse the event loop. Qt supports GLib2 loops, but only as long as they are created by Qt. So you create a dummy QCoreApplication, start the event loop. Then you coerce GTK into using the glib event loop Qt created.
After that, you populate your QObjects I mentionned above. The `Q_PROPERTY` stuff is the important part. It *has* to be fully implemented for QML to ever work. For Qt5, you need to use Qt containers. This means porting your lists and other C++ types (or glib types) to Qt. For Qt6, I think you can get away with some of that, but not Qt5.
Then, make all the signals work. It is important that all properties have signals. The signals must be reliable. QML heavily relies on events for literally everything. Without events, your UX gets out of sync and crash.
The next part is models. Turn all list with selections to models. Don't try to render stuff using for-loops in QML, this is a terrible idea and will explode in your face. Qt Models are annoying to write (and get repetitive very fast), but reliable list models really greatly simplify the QML code.
When you have all those QObject to reflect your current codebase, you make a companion app. This is a small window (or LAN/Network smartphone UI using QtRemoteObjects).
Now you are ready for the UI. Add little features, one by one. Don't try to do everything at once. Again, as long as you can, keep the wx/GTK window alive and fully functional. Your app will look wierd with 1 wx window and 1 QtQuick window. However, having the fully functional old UI let you press buttons there and see the results being updated in QML. That let you polish/debug your signal/q_property code step by step.
Once you are "done" with your port, strip the UI code from the old codebase. Then refactor/clean the logic and turn it into a library. Then start merging your QObject shims and logic classes into a single class.
If you get there, congradulation, your port is complete. Time to annoy your users with a bunch of changes.
With Qt 4/5, there is an environment variable, to play with. It sill runs like crap and is now deprecated.
edit: Of course, GTK4 have "real" backends for both Vulkan and OpenGL. They implement scene graphs like QtQuick rather than building a big bitmap like GTK2, GTK3 and QtWidgets.
On KDE HiDPI, the audio input/output device selector positions the dropdown boxes according to 100% scaling, but they're sized according to 125% scaling, so they overlap!
It's still called an export, but it's basically doing exactly what you're asking for.
It's because the format you want (regardless of it being the same format you started with) can't store quite as much metadata about your changes as the app's native format.
Maybe a custom config profile that is very easy to tune, import and export would allow redesign to get radical without compromising old users
https://www.blackmagicdesign.com/products/davinciresolve/fai...
I gave up every time I tried to use it because the UI was fugly to the point of being distracting.
> If I was a rich philanthropist I'd throw them some money to gut the core of the software and rebuild a decent user interface around it.
Unless I’m misremembering the software, years ago (a decade?) I planned on doing the next best thing and work on a new icon and UI for them, but soon found an official page which said they weren’t interested in such contributions. The page existed because people kept offering.
There’s another commenter on this thread who’s working with them on a redesign, so I’m glad they changed their minds.
To me, plugins are something that provides additional functionality to the native abilities of the program.
That said, an API around the UI would be great. A lot of commercial audio platforms have moved in this direction, iPad control of commercial mixing consoles and effects processors is common in the industry now. I'd love to see PC-based audio applications go down the same path.
That's what audacity plugins do? I think the most important distinction of a "plugin" is that it can be created, distributed, and installed with no modification or recompile of the Audacity source. Therefore, plugins are relatively easy to use for non-technical users, and can be mixed together with a low fear of conflict. Two separate programs that consume an API, on the other hand, cannot usually be mixed together if both are needed.
(& github: https://github.com/1j01/jspaint )
Audacity, VLC, Blender, KeePass, Inkscape, OBS, etc (there's many more but those are the ones I use regularly). Programs that have been around forever, are used by millions every day, and yet continue to do it (and do it damn well) just because they want to.
For the clients, 2.x uses KDBX files, but is also compatible with the older KDB files, while 1.x can only use the older KDB files.
Baby Mode - I know this has a history of sucking, but a lot of audacities UI complaints are from users who need one small thing once in a while.
Less "G" in the GUI. Audacity is a whole bunch of hard to group commands. Maybe they should just bite the bullet, and incorporate some 80s-ish text navigation UI elements. People are googling "how do I X" anyway.
When I was working in college radio we used to build quick liners and sweeps in Audacity instead of loading up the heavier programs (I can't remember what they were now actually - maybe Nexgen?) for editing and mixing.
The genius of the application is that it does not try to be more than a waveform editor. Oftentimes, no matter if you are new to audio production or a veteran audio technician, you just need to edit some sound, and Audacity lets you get it done in a easy enough way for newbies, and in a complex enough way for veterans.
Maintainers of projects like these should carry themselves with pride. Projects that stand the test of time and continue to deliver exactly what you needed is what makes the IT-world go around.
Well done.
Its great to have an array of these tools provided for free
I've recorded 70+ episodes of the Running in Production podcast[0] and to get the highest quality audio I can for the show I ask guests to locally record their side of the conversation with Audacity while I do the same on my end. Then we talk in real-time over Zoom to have the actual conversation.
Out of 70+ episodes there hasn't been a single case where something went wrong due to Audacity. These are shows where we're continuously recording for 60-90 minutes too.
All I ended up doing was write up a quick guide. Basically how to download it, making sure your "good" mic is selected and doing a test recording. No one has ever complained that the process was too involved or hard to follow. Most folks get set up in less than 2 minutes with no assistance and most guests have never recorded audio before.
---
3. Locally recording our own individual audio tracks
Programs like Zoom and Google Hangouts are great for talking in real-time but their audio quality is extremely low for a podcast.
So we'll be recording our own individual audio tracks. Basically that means you'll want to download a tool so that you can press record on your own computer, record your side of things and then be in a position to send me the exported result of that. Then I'll combine our tracks together in the end.
Don't worry, we'll do an audio test and double check things together on the call to make sure things are set up properly before we hit record.
If you're not already familiar with tools to locally record your own audio track you can try using https://www.audacityteam.org/. It's free, open source and works on all major platforms. It's a fantastic tool.
After starting Audacity there will be a drop down box near the top of the toolbar where you can select your microphone. If you have multiple microphones please make sure your best microphone is selected.
macOS and Linux users can use the defaults for everything else. If you're on Windows there is a drop down box that says MME to the left of where you pick your microphone. You should change that to Windows WASAPI to ensure you get good quality audio.
Next up you can try recording yourself a few times to get the hang of the program. You can do that by pressing the big red button. After doing so when you speak into your microphone you should see a bunch of blue bars and lines scroll across your screen. That's good! It means your microphone is picking up your voice.
You can confirm if things recorded properly by pressing stop and then playing back your recording. You should hear yourself loud and clear. If you can't then make sure your headphones or speakers are selected in the drop down box to the right of your mic.
If you want to send me a sample that would be fine, but you don't have to.
After we finish our call, it will be very important to stop the recording, save the project and then export it to both wav and mp3 files (just to be safe). You can do that by going to the File menu and then picking Save Project -> Save Project. You can save it anywhere you want.
That will ensure your recording gets saved in case something catastrophic happens while exporting the files, such as the power going out or Audacity crashing for whatever reason.
Lastly, you'll want to do a File -> Export and then choose wav. Once that finishes you'll want to do the same thing for mp3. The default settings are fine.
Keep in mind the recording will be roughly 60 minutes long when we do it for real which will take up about 400-500 MB of disk space, so make sure you have at least 1 GB of space to be safe before recording.
I've also written an extensive guide for getting the best possible results with recording speech: "Voice recording and processing for talks, streaming and conferencing"[1]. Hope it can be of use.
1. https://indiscipline.github.io/post/voice-sound-reference/
That's so simple and so obvious that I'll punish myself 1000 years for not having thought about it :-)
I thought about using 1 of many online services for this but they all came with very big warnings and potential issues like audio drift (tracks get more and more out of sync as time goes on), garbled quality or worse. It ultimately boiled down to not feeling like I could trust any of these services.
So Audacity helped me to learn a foreign language. Thanks!
But I can see how it will be helpful to users in general.
macOS has a really interesting feature that allows bag of files to appear like a single file to users but it’s actually just a directory and you can still access the files inside by opening it as a directory. Of course that doesn’t help for cross platform software though, as on other platforms you will still only see it as the bag of files that it really is.
I think this is what you're referring to:
https://en.wikipedia.org/wiki/Package_(macOS)
I used to have problems with running out of file descriptors on MacOS, and I recall that the maximum number was 256. I was wondering if this package abstraction could be used to work around it.
But then I checked `ulimit -a` and it looks like on Big Sur the max is now 2560. Progress!
E.g.:
zsh% ls Applications/Firefox.app/Contents
CodeResources Library PkgInfo _CodeSignature
Info.plist MacOS ResourcesAlmost. I was actually referring to https://en.wikipedia.org/wiki/Bundle_(macOS) which is the same concept.
See also https://developer.apple.com/library/archive/documentation/Mi...
But I struggle to understand the criteria that a "package" must satisfy to qualify as a "bundle". According to your second link a bundle is "A directory with an internal structure specified by Core Foundation Bundle Services." So there's a finite list of bundle file types, maybe?
No, third party software can define bundles too.
Fine. I tracked down the relevant official documentation:
https://developer.apple.com/library/archive/documentation/Co...
> • A package is any directory that the Finder presents to the user as if it were a single file.
> • A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.
[...]
> The Finder considers a directory to be a package if any of the following conditions are true:
> • The directory has a known filename extension: .app, .bundle, .framework, .plugin, .kext, and so on.
> • The directory has an extension that some other application claims represents a package type; see Document Packages.
> • The directory has its package bit set.
Whether Audacity is actually doing this, I don't know.
$ echo "select name, sz from zip" | sqlite3 -table mb.zip
+---------+--------+
| name | sz |
+---------+--------+
| MB.EXE | 125952 |
| MB.DOC | 1225 |
| MB2.DOC | 9158 |
+---------+--------+
$ sqlite3 new_archive.db -A --create log.txt
$ sqlite3 new_archive.db -A --list
log.txtHaving used Audacity quite a bit, my impression is the exact opposite. Indeed, those traits are exactly why Audacity's UI is currently as "clunky" as it is: because there's a veritable smörgåsbord of features that need encapsulated.
"Audacity is the GIMP of audio" is perfectly accurate in this regard. But GIMP ain't Inkscape, and Audacity ain't Ardour.
This statement brings back a fond memory for me. I was first introduced to open-source software in the late 90s, when I was in high school. GIMP was one of the best known and most popular pieces of open-source software at the time. At the time there wasn't really an equivalent open-source equivalent for audio that was nearly as feature rich or popular.
I remember coming across some programmers around that time who were trying to write "GIMP for audio" -- they called it GWAMP (Gnu Wave Audio Manipulation Program) -- but it never really took off.
Then a few years later, when I was in college, I came across a programmer named Dominic Mazzoni who was working on this pre-1.0 program he called Audacity. It was still in the early stages, and didn't have anyone else working on it except his PhD advisor who had written a lot of the DSP code. Dominic and I hit it off, and I spent a lot of my college free time hacking on it, as other contributors started joining the effort too. And then it went on to succeed beyond my wildest dreams (thanks mostly to Dominic and others -- I was just in the right place at the right time).
If you had told me in the 90s that I'd have a chance to get in on the ground floor of a program that, 20 years later, was still being called the "GIMP of audio", it would have sounded too good to be true.
There's a section that references .aup files, see 2.6. BlockFiles (Audacity 3.0.0 introduces the .aup3 file format)
The most memorable parts of this to me was wXWidgets. Here's ShuttleGUI:
https://github.com/audacity/audacity/blob/master/src/Shuttle...
[0] https://en.flossmanuals.net/audacity/_full/
[1] https://en.flossmanuals.net/audacity/_info/
[PDF] https://flossmanuals.net/pub/audacity-en-2018.02.pdf
[EPub] https://flossmanuals.net/pub/audacity-en-2018.02.epub
Audacity 2.2.0 Released - https://news.ycombinator.com/item?id=15621681 - Nov 2017 (146 comments)
The Future of Audacity, Interview with the Team - https://news.ycombinator.com/item?id=9392035 - April 2015 (28 comments)
Removing background noise in Audacity by differencing stereo channels - https://news.ycombinator.com/item?id=6158058 - Aug 2013 (13 comments)
Audacity 2.0 Released - https://news.ycombinator.com/item?id=3714766 - March 2012 (63 comments)
Learning a new language with Audacity - https://news.ycombinator.com/item?id=2962284 - Sept 2011 (9 comments)
> The Blender & Audacity add-on playing both apps in sync - without Jack - so you can edit sound in Audacity and using Blender as video player
[0] https://github.com/tin2tin/audacity_tools_for_blender/
[1] https://twitter.com/tintwotin/status/1371885605735530500
Overall, it looks like it might be a great performance boost when working with highly edited fragments and at worst a slight performance degradation for large unedited tracks.
Thanks Audacity, for an excellent tool!
I just absolutely love this sentiment! It gives me so much faith in their organisation.
So I did another recording to determine the frequency & bit depth, and then opened the dd disk image with those settings. It was pretty obvious from the waveform image which parts of the drive had the recording, and it was perfect.
Interestingly, I got those settings completely wrong at the start, and I could still tell it was music by listening to it, it was just very corrupted sounding!
I had never used a sound manipulation software before, but within 2h (including downloading and installing the software) I was able to import all the files (It was not intuitive, I had to search a bit), cut stuff, put a bit of a piano stuff he played with fade in/out effect and create a nice 2 minute mp3.
I was blown away by the final quality for so little work.
Eric S. Raymond considered Audacity a great example of Linux UI design in "The Art of Unix Programming" [1].
I do, however, think mhwaveedit [2] deserves more attention. A really well thought out UI; excellent for small edits on Linux. It was also a direct inspiration for the writer of the mtpaint graphics editor [3].
0: https://forum.audacityteam.org/viewtopic.php?t=39688#p102880
1: http://www.catb.org/esr/writings/taoup/html/ch06s01.html#aud...
I prefer AzPainter[0] instead of mtPaint.
These performance issues motivated me to build https://wavtool.com. It's faster for basic recording and navigation, and runs entirely in the browser. It also has a code editor built in, and a bunch of community-made audio effects written in JS.
25 years ago it was reasonable to argue that you just couldn't afford the performance cost of calculating and displaying even a halfway accurate approximation, but that's a pretty weak argument today.
Stairstep displays reinforce a bunch of erroneous beliefs about digital audio. There are of course some great material like https://wiki.xiph.org/Videos/Digital_Show_and_Tell to debunk those beliefs, but they'd be less likely to arise if all the tooling people used didn't implicitly reinforce them.
Did they fix that any time since? Sadly I would guess not.
Frankly, that approximation would be wrong in many cases, and would very significantly complicate the visual presentation as well as impact UX.
There is a lot of work here. Actual gains are marginal, risks quite high.
Those steps are the data being manipulated.
Displaying the product of the data only would be confusing in another direction.
So, both would be required.
That is where all the work is, and in terms of priority the case for this kind of thing is super weak, IMHO.
Seems to me you are framing this as a fix when it is not actually a problem.
It is an enhancement request.
While I agree with you, and learned about these things myself! I felt much better about a lot of concerns, but I must also say I find very little utility in a computed visualization of this kind.
It would be spiffy, but would add almost no real value.
A stairstep isn't "the actual data". The actual data is a series of impulses. While it is possible that somewhere inside a component of your hardware there's a DAC which is creating zero order hold signals to feed into a reconstruction filter as one cheap way to make the PCM data into analogue audio, Audacity has no way to know that and there's no reason either Audacity or its user should care.
> Frankly, that approximation would be wrong in many cases
You could easily plot a curve that's more accurate than the user's display. You can't see inaccuracies that are smaller than a pixel. There's already suitable code for this calculation (it's called a resampler) inside Audacity.
> Those steps are the data being manipulated.
Again nope, you're manipulating PCM data, an Excel-style view of lists of signed integers would be much closer to "the data being manipulated" in this sense but you presumably don't think that's a good idea.
Your apparent confusion as to what's real here despite having "learned about these things" is exactly why I was pleased to see in the other reply that Audacity now shows lollipop sticks illustrating the actual impulses once you zoom in far enough to see them.
If lollipops are the thing we're showing most users for the next twenty years I have my hopes that conversations like this will become no more necessary than arguing with Flat Earthers.
Which is it?
There was an input signal. Those samples will reproduce it. (Assuming an input matched to the sampling capability under discussion.)
That is what the video you linked tells people.
I am definitely one of the people, and have shared that exact one many times.
Showing people the input waveform makes sense. Overlaying it with the data captured also makes sense.
An approximation does not make sense.
Can we show them the input signal that generated the data easily? If so, great. Let us do that.
What I meant by "real data" is that list of integers. That is what is in the machine.
We both know that is not what comes out, nor what came in, nor what people hear.
Personally, I have always evaluated that by actually listening, or using my scope, same way that engineer did in the pretty great video you linked.
We'd be trying to draw a curve (a band limited audio signal is a smooth curve, although I guess in the very degenerate case that it's completely silent that curve is also a perfectly flat line), on a display made of rectangular pixels, so, that is always going to be an approximation, but that's really neither here nor there.
> Can we show them the input signal that generated the data easily? If so, great. Let us do that.
Yes, this is very easy to do, in the video you say you've shared many times it shows this (among many other things) because it isn't hard, unless your idea of a fast computer is a 20MHz 80386 or something, in which case, yeah, that's not easy and maybe isn't worth your time.
Or what they have chosen to do now (lollipop graph) is also fine, if you zoom into the lollipop graph on your 44.1kHz recording of a Mariah Carey vocal it's still fine, it only starts to get a bit confusing (making the smooth curve valuable to see what's actually happening) at really high frequencies say, 15-20kHz.
Well, in that video he is reproducing inputs with only modest frequency complexity.
And by approximation, I do not mean pixels. I do mean a reconstruction of the input. That drawn as pixels is fine.
Won't the compute burden depend on the frequency domain complexity of the input signal?
And if that is approximated, I maintain the existing UI representation is just fine, as it is functional.
Monty is making them with a signal generator, so that you can easily see what's going on and (if you have suitable gear) you can reproduce the results. The exact same phenomenon would happen for some hypothetical complicated analogue signal. Notice that Monty also demonstrates a square wave, which is in fact the maximum possible "frequency complexity" because of how audio is defined, even though chances are you're still thinking about it as very simple.
> Won't the compute burden depend on the frequency domain complexity of the input signal?
No, it's just resampling, the same way you would to go from say 44.1kHz (from a CD) to 48kHz (typical modern fixed rate DAC in a cheap PC), except you're maybe going from 40 samples to 1000 pixels if you've zoomed in that far. It'd use a windowed sinc function.
If the software renders the output shown on the scope, fine! That is what people will get.
How useful is that?
The case you made, which is to beat back misconceptions about what the output will be, is a good one. I do not disagree. Then again, just sharing that video does a very similar thing.
I do however think that display and UX would / could be more complex and would not actually get anyone anything new.
In my case, after learning the things presented in that video, I first used my scope, which is actually very similar, if not identical to the one in the video, to play with some signals and explore performance on various devices,circuits and code I found of interest.
Then what?
From an audio editing POV?
Nothing, other than I understand where seeing sample data breaks down in terms of what will be output and heard. That is nice, and seeing it would be nice too, but unnecessary.
Now, when building my own stuff, knowing what to expect is just as nice. I can hook up a scope and validate it.
It does make me wonder about the inverse questions! My square wave is a mess!
Despite fancy rendering and interpolation we may well be back to sharing the video.
I found https://thewelltemperedcomputer.com/KB/SRC.htm to be interesting. Near the bottom, it has sinc-interpolated visualizations of discrete-time signals (though saying that resampling is bad, because of a Nyquist-frequency signal not surviving an upsample and downsample, is misleading). What program is that?
Congrats audaciteam!
Disclaimer: I was a contributor a long time ago to the noise filter effect.
Avidemux is nice, but I can hardly add text or do simple effect with it, maybe with some scripting?
The new windows video editor is pretty good too, but features are quite limited.
I have some nice ideas for /r/highqualitygifs but I really don't want to use a professional video editor.
There are libraries to decode and render video with sfml and sdl, and i guess I could easily build a tailored editor myself with adequate ffmpeg commands...
Very intuitive GUI and easy to learn and to teach to others.
I was able to teach a musician friend of mine to be able to lay tracks, edit and splice in about 20 minutes even though had very little technical abilities.
Sometimes too much is a bad thing.
Trying to learn something like Pro Tools as a beginner is enough to scare someone away from digital recording/editing
It's such a great tool for editing bits of audio fast. I think the UI is fine for what it does to be honest .
Is there not a "safer" way in 2021?
My turn: Creative WaveStudio (came with some of the original Sound Blaster cards back in the Win3.1 days) and n-Track Studio
Personally I only need pretty basic wave editing and am happy with OcenAudio (https://ocenaudio.com - free but closed source), it’s the closest thing I’ve found to Cool Edit 2000 (which I still think is the best wave editor ever!) and has quite a nice UI.
It took me some time to remember to avoid it.
I do luvs me Audacity, though.
Good show!
[0] https://twitter.com/FossTorrents/status/1372176177708818433
This is good news indeed. Previous versions of Audacity are so buggy that they're barely usable. Version 2.4.2 crashed more often than not when I used it.
I've used Audacity from time to time over the past 15 years or so. I've had so many bad experiences with it that I try to use alternatives whenever reasonable. I've used it on Macintosh, Windows, and Linux on different hardware configurations. It's the only piece of software that has ever physically hurt me, to my knowledge (on some platforms it adjusts system volume without warning).
It's been buggy as hell and I've had some profoundly negative experiences using it.
Last time I used Audacity, it was version 2.4.2, which is the previous version before 3.0. It adjusted the system volume against my wishes, worked for about five minutes, and crashed. I gave it another shot—tried running it again, but it crashed again fairly quickly. I have no fucking clue what I could possibly be doing wrong. I was not trying to make it crash, I didn’t think I was doing anything unusual. No esoteric formats, no bizarre hardware configurations, no plugins.
When you make comments like that, I feel like my concerns are just being dismissed as invalid. The argument that Audacity is popular and therefore it must not be buggy makes no sense to me. People will use buggy software if they still get work done.
Firstly, I'm mildly sorry to hear that, but I don't know you, and whether you are tired or not and about what...seems none of my business. Nothing personal: "I am tired of.." doesn't seem a good start to a comment on HN.
"Audacity is popular and therefore it must not be buggy" is not remotely my argument. You talk as if everyone using it experiences bugs very frequently – "so buggy [it's] barely usable" – which isn't at all true, in my experience. (My anecdata seems relevant, when someone talks as if claiming everyone had experience X, and I had the opposite.)
Maybe if you restrain yourself to talking about your experience, instead of talking as if everyone must have that same experience, you wouldn't get "tired of having people tell me that my criticisms of Audacity are invalid".
"Previous versions of Audacity are so buggy that they're barely usable" strikes me as ridiculous. Because it sounds like you are trying to speak on behalf of every user. I'm sorry you had so many problems with Audacity. I hope it's ok for me to say that I never had any, and never heard of any, until reading your words, although I'm not an expert. Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
I said that it crashed “when I used it”. I thought that was enough to make it explicit that I was talking about my own experiences—but I don’t think that should be necessary.
Just like when you talk about how Audacity doesn’t crash when you use it, I know you’re talking about your experiences, and not anyone else’s.
> Because it sounds like you are trying to speak on behalf of every user.
That interpretation is incorrect.
> Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
What you said is that my criticisms didn’t seem “fair”. I do a lot of software development—it’s my job—and when a piece of software I write works for user X and crashes for user Y, my conclusion is usually “my software is buggy”. If user Y complains that my software is buggy, I would consider their complaints completely valid and want to fix it—and it looks like the Audacity team has made some great strides fixing bugs that don’t affect everyone equally—which is a very typical experience when fixing bugs.
To quote the release notes for version 3.0, “Some [bugs] though were really juicy high priority bugs that would have mattered a lot to the people affected by them.” It sounds like the Audacity team, at the very least, were aware that some users had very negative experiences with the software and I’m glad that they’re making stability a priority.