Open directly from an URL

Hello! Would be very useful can open audio tracks directly from Youtube, typing the URL in Files->Open.



It would, but a lot of times it doesn’t work out that way. The link you see is probably not the actual sound or video link. You would be trying to open a routing tag and keeping up with all the different routing tricks would be too much work.

Isn’t there non-player software that can directly download content like that?

And then there’s the copyright issue.


Audacity doesn’t have the necessary security to download from the internet.

Yes of course (if you have copyright holders’ permission) the obvious solution is to use an official extension for your web browser to download from YouTube. This is usually safer than going to a web site that lets you paste in the YouTube URL and download the audio or video. You can harm your computer that way, especially if they make you download a “helper” application to do the job.


I would like this topic revisited and this feature implemented, please. In 2021, this is an essential feature which Audacity is currently lacking.

It’s such a simple feature to implement - a new “File” menu option:

  • “Open → From Web/Url/Stream…”


  • “Import → From Web/Url/Stream…”

A simple one-line text input box appears and the user inputs their desired URL. On the back-end/in the coding, a simple wget or cURL command points to whatever URL/file location the user has entered. The file downloads to a temporary/cached directory somewhere and the regular Audacity audio import process begins.

If the URL/location entered doesn’t directly/quickly yield a recognized audio file (WAV, MP3, OGG, AIFF, FLAC, MP4, etc.) then simply return a one-sentence message to the user: “The location you have entered is not a direct link to a supported audio file.”

Countless other popular/widely-used media tools have this feature built in, such as VLC Media Player for example:

  • “Media → Import network stream…”

I don’t feel this is really relevant or applicable here. Any audio that can be opened by/imported into Audacity can potentially be copyrighted content - this is simply another way to access an audio file - a way that is essential in 2021 when the content a user is trying to access is more and more likely to be located on an external network/on the cloud/on an internet server. I can insert a commercially-released compact audio disc from 1992 into my computer and with little difficulty import that content into Audacity and that would definitely be copyrighted material. It’s not Audacity’s job to police whether the user is working with copyrighted material or not. That would be getting into YouTube file uploading and policing territory and would be a nightmare and it would be ridiculous and infuriating if Audacity started analyzing any snippet of audio that is imported to check for copyrighted content. Audacity is simply a tool - the onus or liability is on the person using Audacity, not on the tool itself. If adding a few lines of simple code to implement this feature of being able to quickly open an audio file from an internet source still worries you so much about content potentially being copyrighted, then add a simple one-sentence disclaimer warning that “material from the Internet may be copyright protected content - only import audio content for which you are the owner or for which you have permission from the owner to import… blah blah blah” and move on.

I’m not saying someone should be able to paste a YouTube video URL and have the audio instantly imported into Audacity (though other commonly used/popular media tools, such as VLC Media Player again for example, do allow the user to simply input the URL to a YouTube video and the media is opened - again, this is on the user, and is not the duty or responsibility of the media tool itself to police or worry about). If someone inputs a YouTube video URL/link, then just simply have it return the “The location you have entered is not a direct link to a supported audio file.” message as suggested above.

I have gone ahead and posted this as a feature request on the Audacity Github site because I’m not sure if this forum is the correct place to make a new feature request?

Is this forum also still the best place to make support requests, or should this just be done in the Audacity Github “Issues” area?

There is also the issue of security: malware can be packaged with/in audio, e.g. …
If you have Audacity whitelisted in your antivirus to make it run more reliably,
then a download direct into Audacity would be unchecked. :open_mouth:

There is also the issue of security: malware can be packaged with/in audio

I read the article and found it to be of little value and quite frankly, just alarmist.
Stenography is nothing new.
Just because code can be hidden/included in a wav (or other audio file), does not present a danger.
I know of no media player (Audacity included), that will suddenly execute that malicious code.

At worst, it will just be “random” noise and sound terrible.
The media player/editor/DAW, cannot differentiate between audio data (samples) and binary code.

You can even try it yourself.
Compile a simple C pgm that just pops up a message box.
Then, import that compiled code as “raw” header-less audio into Audacity and export as a wav.
It just sound like, well,… noise.

You’re not a Windows user then.

Not necessarily involving steganography: the malware could be downloaded with/instead-of the intended audio file.

says not a Windows user.

Well my point still stands, the initial “message” is harmless and I bet it’s not even in the actual media part of the file,
but rather as a xml (or even hta) which is embedded in the meta section of a wmv or wma which are really just
Windows-centric codecs and nothing like plain vanilla PCM wav or even MP3’s which can at most,
support ID3 tags and cover art.

It’s only used to try fool potential victims to go download a malware executable disguised as a codec pack.
It’s this executable that is dangerous.
Many people also get fooled by emails, social media posts, etc.

Over and above, why do people still insist on using vulnerable bits of software like WMP and IE with it’s terrible ActiveX plugins?
WMV and WMA files are part of Microsoft’s ASF family of codecs, which contains meta data areas, and one of them is scripting code
for WMV/A where it get’s the DRM key and presumably also popping up message boxes.
From Wikipedia:
Screen Shot 2021-07-11 at 10.24.09 PM.png
Would that message have even popped up in something like a proper media player like VLC?

Not necessarily involving steganography: the malware could be downloaded with/instead-of the intended audio file.

Of course it can, but that applies to any download, whether one uses a browser, a dedicated downloader, wget or
even Audacity.

Let’s look at it from the perspective of the OP’s request:
Assuming now that Audacity had a “get from a URL” feature, and a nasty .exe came along with the wanted audio file,
Audacity would simply place it on an audio track, it would sound terrible but it certainly would not be executed.

All audio files have headers, presumably the devs of Audacity would at least check for the most popular ones when a download
has been received and is tested before Audacity lays it down on a track.

The OP also specifically mentioned downloading from YouTube, no ways are you going to get a .exe/.com/.dll served to you from YouTube.

Not necessarily true.

ASF files can contain script commands that are run automatically by Windows Media Player (See: Even if such scripts can’t do anything directly dangerous, they could still trick users into doing something dangerous. One example is described here:

A more common risk with downloaded audio files comes from the fact that Windows and macOS hide the file extension by default, thus an executable file can be made to look like an audio file:
“Rare recording.mp3.exe” may look like “Rare recording.mp3”
Given that many people play audio files by double clicking on the audio file, there’s an obvious danger.

Having said that, I think there are more likely reasons to not download files directly into Audacity.

  • Whereas a music player can start playing a file before it has finished downloading, it would be a fatal error if Audacity tried to apply an effect to a file before the download completed.
  • Normally Audacity works on a copy of the file that is being edited. This adds a level of safety in that no matter what goes wrong, the original version of the imported file is not affected. This would not be the case when downloading directly into Audacity. Say that you had just bought an album from Amazon and downloaded directly into Audacity, then for some reason Audacity crashed. You could potentially lose your one and only copy of the album, and would have to buy it again. (No doubt you would download it safely the second time before importing it into Audacity - but better if you had done that the first time).
  • Audacity does not act directly on audio files. Audacity acts on blocks of 32-bit audio data (called “blockfiles”) that have been recorded or copied from a file. Audacity would still need to copy the audio data and convert it into “blockfiles” before it could be worked on.

When all is considered, I don’t see much advantage in downloading directly into Audacity, but I do see increased risk, and the possibility that Audacity could be accused of encouraging making pirate copies of copyrighted material. Unless Audacity implemented DRM (which is problematic for open source software and likely to be extremely unpopular), I expect that there would be some degree of legal jeopardy.

That would be a direct breach of YouTube’s terms of service.

The following restrictions apply to your use of the Service. > You are not allowed to> :

  1. access, reproduce, > download> , distribute, transmit, broadcast, display, sell, license, alter, modify or otherwise use any part of the Service or any Content except: (a) as specifically permitted by the Service; (b) with prior written permission from YouTube and, if applicable, the respective rights holders; or (c) as permitted by applicable law;

(highlighting mine)

ASF files can contain script commands that are run automatically by Windows Media Player

Then WMP is even worse than I thought, and in one of my previous posts I specifically asked/wondered why
people still put themselves at risk using WMP.
WMV and WMA files are terrible things, I have been in the TV business (and before that in radio) for many, many
years and have never had to deal with those codecs.
I still maintain that the article that trebor linked to, is alarmist, as 99% of media files pose no threat.
That is certainly true of the most common, wav, mp3, mov, mp4, …

That would be a direct breach of YouTube’s terms of service.

Yes it would, but like it or not, people do it.
I don’t think it’s Audacity’s place to play policeman.
By all means include a warning and disclaimer and let the individual decide.

Bottom line is, in today’s ever more connected and “online” world, more and more media will arrive by direct downloads.

I personally have no use for downloading something directly with Audacity, but can understand that others would find it
useful and probably shorten/simplify their workflows.

As to the default hiding of extensions, yes that is true and quite dumb in my opinion.
Users have to take some responsibility when using a tool like a computer, just like an electric drill, hammer etc.
Part of that responsibility is at least having a basic knowledge of some dangers and pitfalls when it comes to files.
To hold back a feature or addition just to protect the lowest common denominator is certainly not progress.


Unless Audacity implemented DRM (which is problematic for open source software and likely to be extremely unpopular), I expect that there would be some degree of legal jeopardy.

Are you sure Steve?
Surely then the same applies to any downloader including VLC, wget and all web browsers.

The other point you made about Audacity crashing if applying an effect when the file has not fully downloaded, is very valid.
However that could be overcome in code, by checking for a completed download first.

I think that to get it to work with YouTube would be for Audacity to pretend to be a web browser, and so trick the YouTube server into delivering content that should be served to someone watching the content in a web browser. I’m not a lawyer, but in my opinion that would take Audacity beyond “condoning” illegal copying, that would take Audacity into “aiding and abetting”.

On the other hand, direct download “could” be made possible from sources that support legal downloading of content. Whether or not there’s demand for that, I don’t know.

I think that to get it to work with YouTube would be for Audacity to pretend to be a web browser, and so trick the YouTube server into delivering content that should be served to someone watching the content in a web browser.

Were are getting into semantics here as to what constitutes a web browser.
A web browser itself, does not download anything, it simply “decodes” the data and displays it or plays it.
There is other code in the browser that deals with the actual download, if Audacity used the same (or similar) code, well…

Over and above, what about software like wget?
It has an option to allow a user to change the “User Agent”.
(For those that don’t know, the “User Agent” is some text that identifies your browser to websites).

For example, a very common “User Agent” for people using Chrome on Mac is:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4188.121 Safari/637.36

An example of changing the “User Agent”:
(Simulating IE 6 on Windows NT 5.1 (In other words Win XP)

$ wget -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" ""

The fact that a user may change the “User Agent”, is entirely the individuals doing and nothing to do with wget, or Audacity or any other software.

If it was a problem, the people that coded wget, would have been in hot water a long time ago.

BTW, VLC and even Chrome, let you modify the “User Agent”, you just have to know where to do it. :wink:
I don’t see them being sued.

To use an example, it’s like authorities trying to ban the sale of wire cutters, because some people may use them to cut a fence
and break into a property.
Or, ban printers because they can be used to print false documents.

People use (and abuse) tools all the time, the use and responsibility lies with the user.

There are thousands of sites that allow direct downloads and thousands of legitimate reasons why someone may
want to download them.
The fact that some people may use a feature to do something they shouldn’t, well that is their problem
and not that of the creators or coders.

lol… Just to clarify here: as I stated in my earlier post I am NOT suggesting Audacity be able to directly import/extract audio from YouTube video links:

I just want to be able to open a file from a URL. Apparently this functionality is already built-into Windows File Explorer and one can type an HTTP URL into the location bar in the File Open dialogue (I will have to get on my Windows machine and test this). This lets Windows itself manage the actual downloading of the file/scanning for any potential malware.

Apparently this type of file management operation (opening from an HTTP URL source) is also available/built-in to many distributions of Linux, which use GtkFileChooser as the file open/file management interface, but it is up to the application developer whether or not this feature has been supported/activated. I tried typing a direct .mp3 file URL into the “File Import/Open” dialog that appears in Audacity on Linux and it seems the feature has not been supported or activated. ​Here are a couple of links referencing this functionality:

Couldn’t there potentially be the same type of bundled malware in any file opened from anywhere? If someone sends me a file on Google Drive, or via email, it could still potentially come bundled along with malicious code. It’s true that Google Drive/many modern email programs have built-in detection and file scanning features for malware, but not everyone uses these features or has them. And I also agree that they’re not likely to be executed if the file content is simply turned into audio bits/blocks.

These are valid points, but as I stated in my original post I would expect Audacity would work from a copy/temp/cached version of the file and not directly with the file itself. And most (all?) media files accessed via a URL link (a generic example) are going to be read-only anyway…

This is a standard feature on so many other applications. I’m sure there is generic language available for a “Legal/TOS” read-me file that can be used to protect Audacity from any liability. I"m not asking for Audacity to load and convert YouTube videos and then extract the audio. I just want to be able to directly open (or I guess I should say load a copy of) a media file from an HTTP location. If the file format isn’t one of the five or six common audio/media file formats than there can be an error message stating that this provided URL is not a direct link to a supported audio file (as I also mentioned initially). This feature/function is no different from the current “File → Import…” functionality/feature of Audacity. I can just as easily access copyrighted material from a local file.

Yes I saw that, and I agree that it is an important distinction from the original post.

I would expect that the developer’s answer to the original post would be “no”, simply on the grounds of potential exposure to being sued. The law in the US is very clear that “it is illegal to make a copy of content if you do not have the permission of the copyright owner”. It is very unlikely that a company would go after an individual for illegally downloading copyrighted material without permission - more likely they would go after a company that they see to be implicated in the activity (as happened with

That depends on the file browser. That functionality is not present in Thunar (there may be a plug-in available to add that feature, but I’ve not looked). I believe that Nautilus file browser (the default for Gnome Desktop) has this feature by default, and also optional plug-ins for integration with dropbox and other cloud storage.

The obvious way to implement this would be:

  1. Download the URL target somewhere
  2. Import the downloaded file in the normal way.

Personally I don’t see much benefit to that at present. I’d rather just download the file to a location of my choosing (using one of the many tools available on my computer, such as Firefox web browser), and then import the downloaded file. I’m not a fan of the “everything and the kitchen sink” approach to software development, mostly because it frequently leads to “bloatware”. I tend to prefer the approach “do one job well”.

Just wanted to say I value and understand/respect your feedback here and appreciate your taking the time to offer it :slight_smile:

You’re welcome, and I trust that you understand that my response included a good amount of personal opinion :wink:

It occurs to me that it would be fairly simple to write a Python script to download a file and then open it in Audacity. When launched from a command line, Audacity may be passed an optional file path. That tells Audacity to import the specified audio file after launch. So a Python script would just need to download a file somewhere, wait for the download to complete, then pass a command to the operating system:

audacity path-to-downloaded-file