Am I the only one who thinks that describing this as a "bug" sounds a bit off? Most bugs don't come with their own updated alert text. It sounds a bit more like they had planned to switch to a different trial method and enabled it earlier than they expected? Or maybe a "rogue" employee added the feature as an experiment and didn't tell anybody?
I love Audio Hijack, and I do use Loopback and SoundSource as well. Windows users love to complain about the fact that we have to pay for this stuff, but forget to mention that no amount of money can give you half of the same functionality on their preferred platform.
I guess you can do some of it using a Windows port of JACK Audio or something, but this isn't trivial to get working - and would still pale in comparison. Why it still is so difficult to route audio in Windows is beyond me.
To give a bit of context; I can sit in a Teams meeting using compressors and saturators and whatnot to make the audio better and put any amount of VST plugins in the chain on my own microphone. At the same time I can mix the output from an ambient track from Spotify with audio from liveatc.net and stream the whole thing to an Icecast server while ripping everything to a file.
Trying to do the same thing on Windows will just drive you insane.
As I was reading this I was hoping that they had completely disabled the limitations and unexpectedly found alternate routes to sustainable profits, or that people suddenly became more willing to pay when there was less pressure to do so.
But I guess the real bug and its outcome was more in line with the (often disappointing) reality that we all share.
So, letting people try it out it for two weeks prevented them from buying it? That doesn't reflect well on customer satisfaction.
I'm sure this is some MBA 101 stuff, but I'm slowly learning that all sales come from a sense of urgency.
A two-week long trial ends and you're not even on the computer? Oh well.
You're recording something longer than 15 minutes that you want completed _right now_ and the only way is to upgrade? Instant purchase.
That doesn't mean that urgency has to come from a place of in-authenticity. In this case, I think the trial time limit is fair. People still get real value (actually for even longer than just two weeks), but if you want the full-offering you have to pay for it. It's a decent balance.
Bingo. The best trials are those that allow the user to determine whether the product is capable of solving the user’s immediate problem without actually solving it unless the product is purchased.
I believe this goes hand in hand with certain types of customers. Purchasing software is often a long-term decision, but many people only need it once. In 15 days, they can complete one or two projects and then forget about it. With a 15-minute limitation, however, you are effectively encouraging them—assuming the quality of your product matches the price—to purchase the software.
So customers were satisfied anyway, but because of the bug their satisfaction did not last enough:-)
I think more than anything it reflects on the fact that most people don't need to record audio all that often. If the product is fine, but you've done all the recording you need, why would you buy it. I would wager that most users never even saw the trial end nag screen simply because they didn't need to open the app anymore.
Audio Hijack is one of the best pieces of software I've ever used. Your takeaway is misguided.
It's much more about aligning the freemium window with the urgency horizon.
A two-week trial won't convert a user that's solved their issue within that window.
I see you weren't around when such shareware was the norm.
With a two weeks trial, the effort to reset the app whenever the restriction popped up was minuscule, hence nobody paid money for it.
So it seems; there's a lot of software you only use incidentally, I suspect this one was right in that spot. Like, once a year or so I need to clean up my hard drive; do I buy a license for a disk usage visualizer, or do I pass because I only use it once? If there's a timed demo I can do my task and forget about it again.
I can’t remember exactly when I started using Audio Hijack, but it might have been from that very first release with the free-trial bug, as I used it to record streaming radio programs beginning around 2002 or 2003. I still use it now. In fact, it’s running on my Mac at this very moment, capturing a live stream from BBC Radio 3.
There aren’t many other applications I have used for so long and with as much satisfaction as Audio Hijack.
Free-trial-based approach to software distribution is not the best. Compared to at least one better alternative, it is:
0) worse when it comes to developer bottom line (if you are being generous, try to provide enough trial time and usable software during trial period, a large chunk of your users will just never pay);
1) worse when it comes to user experience (you are interrupted, you encounter blocked-off functionality, which basically means that upsell is part of core GUI);
2) worse when it comes to developer experience (now you don’t just program one great product, you also have to program into your core GUI the upsell—the various ways in which it becomes restricted while remaining usable);
3) worse when it comes to product improvement (the unhappy user will simply delete the software and you’ll never know what they didn’t like);
4) exactly identical when it comes to honest paying user’s expenses.
No doubt, there are worse options. (One that takes the cake: advertise it as free software, but constantly upsell the “full version” offered on subscription basis.)
What’s that better alternative I’m comparing free trials against, then? Simply offer returns. Buy it, get a license, make your trial period however long you like; don’t like it—request a refund, get money back, get license revoked. What it means is that “tried and not bought” is no longer one of the “happy paths”. As a result, you have a better chance of really understanding what was wrong (if I must ask you for refund, you are in touch with me), and you also exhibit more confidence in your product up front.
I believe App Store in fact works this way. If someone’s thinking about distributing there and feels like the only way to offer a trial is IAP, maybe reconsider: you don’t need that overhead, one fully featured version is enough if your users can already get their money back if they don’t like it. I believe refund process happens automatically for you as a developer, though I’m not sure whether or not the feedback they provided will be forwarded to you. Willing to be corrected.
I like your line of reasoning and you may be right. But as a user I'll probably try a few of the free trial competitors to see if they do what I want before I put money down. I don't always trust front line customer service and the returns process. Sure, maybe you are the good developer who makes it instant and easy. But maybe you're not and either employ dark patterns to keep me in place or don't respond to me at all to return my money. Then I have to consider if the cc charge back process is worth my time and hassle.
Is chargeback a hassle? I’d think it’s absolutely in the interest of the developer to be responsive to refund requests because chargeback is so trivial with a credit card.
If anything, a downside of the approach I advocated for would be if too many dissatisfied users just issue a chargeback and not even request a refund. For a developer, high rate of chargebacks can presumably cause issues for billing.
There is a big penalty for chargebacks, so not presumably, definitely.
Depends on your platform, pricing, how good your product is. Stripe charges $15 per chargeback; if your software costs $100+, it’s probably not a massive concern. If you distribute via a well-run walled garden, chances are it’s not a concern at all.
Chargebacks aren’t so scary. It’s not default recourse for any customer, especially not the type of customer who was financially able to buy your product outright (remember patio11’s advice: the higher you charge, the better educated and less problematic are your customers). You don’t just issue a chargeback if you didn’t like your new iPhone.
Is there already an escrow style middleman?
Want a program, give the middleman some money, get the product.
Within whatever trial period, tell middleman you don't like it, they refund you, program stops working.
Post trial period, money goes to developer.
Provided middleman looks more trustworthy than developer or end user, both win. Roughly what lawyers do in the real world.
If that's not a product already, someone is going to make a killing out of creating it.
As a user, if I make a choice to buy from a developer direct, I already trust that developer and their billing system (like I trust whoever made my OS—there’s no other choice). I am definitely not trusting yet another third party and their PII management practices.
I had the same immediate thought, but I think (as the product provider) it's quite a scary kind of friction to add. Customers already understand the standard subscription model/risk. Adding escrow means they have to learn about a new layer, evaluate it, etc. all in addition to doing the same for your own product.
Plus, never underestimate the ability of funnel customers to just flat out not understand something that seems simple to you. Deviating from norms IME leads to a big drop off. So the value of deviating has to be enough to overcome that.
Free trial is far from the norm. Where else in life does an average person get free trials? Whatever you buy, 99% of the time—be it electronics, clothing, etc.—you make the full payment up front, and if you return it you get a refund.
You don’t just issue a chargeback if you didn’t like you new jacket; you don’t get a free trial on a washing machine.
A major benefit (which, frankly, is a surprise to me that it’s even worth mentioning) is that refunds is the most intuitive process to handle it. Us weathered tech geeks have an intuitive grasp of the shareware business model; however, we are a minority.
I think compared to 'a new escrow platform' (which was the GGP), free trial is vastly more understood. I don't disagree that refunds are a better model, at least for my personal preferences, but most people who have used an app store understand free trials (even if they dislike them).
It's sad that the more generous, user-friendly trial policy led to worse sales. ;-(
I'm actually not so sure. Even if 100% of the signups to the new version came from users trying for the first time, the previous version being essentially free could have got the app a lot of publicity in tutorials, recommendations or even just showing more highly rated or higher in the download charts.
All of that could increase discoverability of the version with only 15 minutes free trial, so it would be essentially trading sales for advertising.
That said, 2 weeks evaluation on a tool you might use only once effectively means it's just free. Those who might have a need say once a month might just uninstall and reinstall it, and feel completely justified because they didn't get their 15 days, only one day.
I agree with you that if the app was indeed "essentially free", it could have seen all the benefits you suggest.
But it wasn't "essentially free". For myself, whenever I encounter a tool I might want to use and it has a limited time trial, I typically skip it unless I'm already fairly certain that I'll keep paying for it after the trial period. I think loss aversion comes in here as well: I'm worried about "wasting" the trial. It's like consumables in a video game: yeah maybe this tool would be useful now, but what if I encounter something later where it would be more useful?
> I'm actually not so sure. Even if 100% of the signups to the new version came from users trying for the first time, the previous version being essentially free could have got the app a lot of publicity in tutorials, recommendations or even just showing more highly rated or higher in the download charts.
You've just described enshittification 101.
it is the unfortunate truth of the world. It's why I just roll my eyes when I see comments like "nagging reminders mean I'll never buy your product!" Those were probably never going to be customers anyway, they're just finding ways to justify it to themselves.
I still have not gotten around to buying WinRaR. On other hand if it stopped working I would probably install something else.
QED
I tried Airfoil to be able to do the following:
- redirect my music (eg Youtube music) to my Apple Homepod
- still play all other audio (eg some podcast or video) on my laptop
but it doesn't work / is buggy / either puts everything in one location or the other
Has anyone here found a good setup to redirect the audio from exactly one app to the Homepod, and keep all the rest on the laptop audio?
so playing with Audio Hijack, it seems my "Airplay" audio output is *only* present in the interface if I'm currently choosing "Airplay" as my default audio output from the system
So basically with Audio Hijack I can do a "hack" which is: - set my laptop to play on Airplay - play some music there - then if I want to listen to something else on my laptop, I have to create an Audio Hijack pipeline to play some other app on my laptop
Obviously I would prefer the reverse: by default play everything on the laptop, and be able to play a specific app on Airplay... but this doesn't seem to be possible because the "Airplay" device "disappears" from the interface as soon as I stop setting it as the default laptop output
One way to deal with a “transient” audio interface tripping various apps on macOS is by creating a virtual multi-output audio device in Audio MIDI Setup (stock app). That device will be persistent, even when one of its output devices is lost.
In my case the interface was AirPods. It was incredibly annoying when various audio software would reset its output device whenever they disconnect or auto-switch to the phone. So, I set up a multi-output device that outputs signal to the pods along with the wired headphone port, and configured audio software to output to that virtual device. After that, there is no flakiness: when the pods are connected then they get the audio, if they aren’t then they don’t get the audio, nothing else needs to be changed.
Interesting! Can you give more details on how to build this virtual audio device? I tried creating one but it doesn't show as output in the Airfoil app, is there something special to do?
Ensure that at least one of the checked output devices is available and normally it should appear among physical outputs in any software, including Airfoil (unless it’s hidden in Airfoil settings). If it doesn’t appear, then I don’t know what’s going on.
I’ve never used Airfoil though. To be honest, I feel like routing audio through a multi-output virtual audio device might defeat the point of the app if it’s meant to play to wireless devices directly.
So what were the same folks who downloaded Audio Hijack doing on versions 1.5 or older at the end of the 15 day trial period? Download it again?
It’s great that they were able to see higher revenues and take the company forward, but I’m wondering if there were additional features that were only on the paid version and not on trial version which helped with retention and growth.
I'd expect that the 15-minute nag screen prompted users when they were most enthusiastic about the app and therefore most inclined to purchase. After 15 days, your initial interest may have waned, or maybe you even completed whatever recording you needed to do in the first place.
A bunch of users who reinstalled the app every 15 days thought "oops devs figured out my trick, now I can't fool them so easily guess better buy it"
Why do we need a paid app to record audio from the system? Surely it's a small enough job for a small utility/script? This seems very Mac ecosystem to me.
It's very "Mac ecosystem" from multiple directions: a paid-for tool that is often free on other platforms, but also a paid-for tool that provides a very nice UX with easier customizability and features than a "small utility/script".
(I don't use Audio Hijack, nor am I in the market for anything like it. But it's obvious from the product page[1] that it's a nice piece of software. I also know that several podcasters I listen to rave about it.)
That's not to say free options don't exist. BlackHole[2] is FOSS.
[1] https://rogueamoeba.com/audiohijack/ [2] https://existential.audio/blackhole/
Audio Hijack isn't a recording app. It's an app that allows you to selectively route audio from individual apps to different destinations - audio interfaces and otherwise.
Its built-in recorder is a small part of what the overall app does.
It drives me nuts how quickly people jump on the criticism bandwagon without bothering to look up what the thing they're criticising actually does first.
Doesn't change the fact that when you try to find out "how do I record desktop audio on my Mac?", the answer is very often "use Audio Hijack", because macOS has no built-in way to record desktop audio. (Not even QuickTime's screen recorder can record desktop audio, only microphones! It's wild.)
These days, OBS is probably a decent alternative, but it's very video focused and very streaming focused, so it's not exactly great for that purpose.
My experience as a musician and huge linux nerd is: sure, it was all free, and very powerful, on linux, but I never actually made music because of the setup times, learning, hacking, and refining the systems.
Since getting a mac and paying for tools like this, the immediacy of being productive has caused me to actually make music.
it's the same with OBS - wow, what a piece of software. I spent a week going through and configuring it. They really thought of everything. Audio Hijack solved my problem in 30 seconds and made sense for my use case while doing it.
Please see the dropbox comment: https://news.ycombinator.com/item?id=9224
That is a question for those that did not make that small (free?) script, not Rogue Amoeba that solved the problem with a paid for app.
For the past like 30 years I feel there's never been a time some commercial Mac program hasn't filled a simple niche. I remember someone last year posting a Show HN for an ffmpeg wrapper for Mac with a limited feature that focused on transcoding and made $9k in the first 4 months.
Or in the late 90s when there was a commercial program that allowed OS 9 to show real-time window previews while dragging rather than merely showing the window border outline.
Once upon a time, Steve Wozniak paid me ten dollars for what was essentially a fancy GUI on top of an AppleScript.
Indeed. Windows has had a Sound Recorder since 3.1, and it's possible to record the currently playing audio if you select the right input (usually named "Stereo Mix" or similar.)
Support for the "Stereo Mix" audio source is a relatively recent thing - and my understanding is that, even now, it's driver-dependent. It most certainly wasn't available in Windows 3.1.
https://en.wikipedia.org/wiki/Windows_Sound_System already had the ability to record from the mixer input (look in the datasheet of the AD1848 codec it uses) and I don't have the DDK to look at currently but I believe it also has an API for the mixer functionality
I used to record the output audio using Sound Recorder, in Windows 95, so the feature goes back at least 30 years.
You don't, depending on your audio hardware. If it has a loopback you can just use sox from the command line to record the loop back channels...