Hello there,
First of all; I am sorry if I am using the wrong community - and sorry for any n00bshow regarding this post since I have not done this before.
Background: To my utter delight, I found a podcast on archive.org that I have been searching for. I have succesfully downloaded all audio files listed under “VBR MP3 FILES” as a .zip file (and as a torrent), and they will download as .mp3-files. I am on Windows 10 (sorry, I will change) and using Firefox as browser.
Very long story short, a lot of files had parse errors in an ID3 editor (Mp3tag), and I incidently found out that most of the files actually seem to be .m4a-files instead of .mp3.
Nonetheless, all URLs on the podcast’s main page show as .mp3-files and will download so if downloaded as a .zip or through torrent. (Or if using Edge, apparantly, which I just tested).
Issue: What is REALLY weird (at least to me) is that if I am right clicking a single link to an episode in Firefox > save link as > my dialog box shows it will save as .m4a-file - which seems to be the correct file type (with no parse errors in Mp3tag) which I naturally would prefer. Screenshot attached.
If been trying to search for an answer my self what is happening, but evidently failed to do so. Does anyone have an answer? And for a bonus; is it possible to batch “save link as”? wget on a Linux machine? downthemall on FF likewise download files as .mp3.
To hopefully reproduce:
- Downloading first episode “2015.11.01 - #1 – 1. Mosebog, kap. 1, vers 1…mp3” for instance as torrent
- Download the same episode by manually browsing the episodes with Firefox > click “VBR MP3” under “download options” > right click “2015.11.01 - #1 – 1. Mosebog, kap. 1, vers 1…mp3” > save link as… > it will hopefully download as .m4a.
THANK you very much in advance! Have a good one.
From what I understand, the end of the URL string is just one of the clues the browser uses to determine the “type” of received data (https://mimesniff.spec.whatwg.org/), and the true behavior depends on the browser’s specific implementation. A part of the process involves actually reading and analyzing a small portion of the received file to see if the file really is the type that the URL claims it is. For example, I started a quick python server, and made it serve the OP image, except I renamed it as a jpg file (without actually converting the image of course). When saving the picture inside the browser, Firefox correctly identifies the file as a png image:
While edge incorrectly tries to save the image as a jpg image:
Regarding your “MP3” file specifically, opening it in a hex editor reveals that the actual file contents identifies itself as an M4A file, despite what the URL claims:
So, you should be good to download them any way you find convenient, and then just renaming them to the proper extension afterwards.
You gotta be kidding me…
I initally tried renaming the files to .m4a but Mp3tag still showed parse error.
… But I tried once more per your suggestion and behold! No parse error. I am not sure what I did differently (obviously user error nonetheless!)
But thank you so much, I learned a lot!
This behavior is because Firefox is using the MIME type of the file on the save as dialog.
Regarding your issue importing them - does renaming the ones in the ZIP to m4a not work? If the issue is mixed mp3s and m4as, you could use something like ffmpeg probe to rename them.
As mentioned above, it was the first thing I did which apparantly did not work - now it does, though! Oh well. Perhaps it was a fresh download that did the trick, I am not sure!
My tech skills are rusting horribly but I tried to briefly take a look at this…
I’m seeing the same behavior with the Firefox save-as file extension being .m4a vs the displayed URL showing .mp3.
Opening either extension in VLC and viewing the codec info (Tools->Codec Info / Ctrl+J) shows the actual encoding to be ‘MPEG AAC Audio (mp4a)’.
I didn’t try grabbing a file from the torrent, but if I use the media tab in Firefox ‘Page Info’ (Ctrl+I) to “save as” the embedded IA player file it suggests a matching .mp3 extension with the displayed address (but the codec is still mp4a).
The main thing I’m not following is what you mean by having parse errors in Mp3tag. So far I haven’t seen any metadata included in either the .mp3 or .m4a downloads (I only tested the first file), they both play audio fine, and if I browse to their directory in Mp3tag (vers. 2.57) it doesn’t seem to show anything unusual to me (empty metadata, no error/alert messages). What exactly is the parse error or how is it behaving differently from what’s expected?
I also just wanted to say “THANK YOU!” for an awesome support post. You posted it to the right community, gave it a short but very descriptive title, gave lots of info about what you’ve tried and the results you’ve experienced – and did so politely :)
That is very kind of you - thank YOU as well! :)
And insightful answer, thank you very much. Forgot all about that VLC could provide such useful information.
The main thing I’m not following is what you mean by having parse errors in Mp3tag.
Indeed, no metadata is present but the “Tag” still shows alot of parse errors (image attached). So if I edited some metadata, it would not show in Windows Explorer for instance.
And yes, audio is all good despite parse errors, but my inner nerd would like to optimise and put in correct tags and what not ;)
Maybe have a read on the 2 filetypes, not sure but I think both is mp3 but m4a has more stuff in it
