ERROR: Import Failed- this is likely caused by a malformed MP3

Hello forum,
I’m using windows 10, for private project I downloaded a song from youtube via “Youtube to MP3 converter” the song seem to play just fine, but when I try to open it with Audacity it keeps showing same error.
" Import Failed- this is likely caused by a malformed MP3
What seems to be the problem? "
Wouldn’t the malformed MP3 not be playing in the first place?
How can I fix it?
Thanks

Which version of Audacity? The current version is 3.0.0 (available here: https://www.audacityteam.org/download/windows/)

Are you using Audacity version 3.0.0? Does it give you any options from there? I haven’t seen that error (thankfully :wink: ).

Wouldn’t the malformed MP3 not be playing in the first place?

Different MP3 decoders handle it differently.

I think there was a change in 3.0.0 to how “imperfect” MP3s are handled. It used to open anything with an MP3 filename extension (including MP4, etc.) so sometimes the file would just be converted to pure-noise. Then the developers made it more strict and it turned-out that there were LOTS of “bad” MP3s that people couldn’t open at all. I think 3.0.0 is supposed be somewhere in the middle.

I have the same problem and an able to reliably reproduce it.

About 15 individual voice recordings are recorded with Audacity 3.0.0.

A PowerShell script concatenates (binary mode) an MP3 preamble, the 15 MP3 files and an MP3 postamble to create a single MP3 output file.
When Audacity v3.0.0, attempts to open or import the concatenated MP3 file, it throws an exception with the message “Import Failed” … “This is likely caused by a malformed MP3.”

However, Audacity v2.3.3 imports, plays, modifies and saves the MP3 file successfully.

After importing and exporting the MP3 file in Audacity v2.3.3, Audacity v3.0.0 successfully imports, plays and saves the MP3 file.

It seems that something changed between v2.3.3 and 3.0.0 to make the concatenated MP3 files distasteful to Audacity v3.0.0. Doing the dance between Audacity versions is quite inconvenient.

P.S. the PowerShell script invokes System.IO.FileStream with Mode: Create, FileAccess: Write, FileShare: None BufferSize: 256KB FileOptions: None

In Audacity 2.3.3 and earlier, there was no error checking on import of MP3 (error checking in the import library was disabled).
This caused problems when importing Opus files because the import library incorrectly assumed that they were malformed MP3 files.

To fix the problem for Opus files, (Audacity 2.4.2) error checking was enabled.
Unfortunately we then discovered that there are a lot of malformed MP3 files in the wild.

In Audacity 3.0.0, error checking of MP3 files has been toned down so that MP3 files that are only slightly (and not critically) malformed can still be imported.

It seems that even the toned down error checking is still rejecting your concatenated MP3s.

The “correct” solution would be to fix your concatenation script so that it produces MP3 that comply with the MP3 standard.
Perhaps you could strip headers from the MP3 before concatenating, then add back one set of file headers (?)

I agree with your suggestion of the ‘correct’ solution. That would require some in-depth development work that wouldn’t be easily shared with other Audacity users.

A more attractive solution might be for some of the Audacity wizards to teach Audacity how to aggregate multiple MP3 files from a text file containing an ordered list of file paths (e.g. TXT, CSV or JSON).

You could use a LOF file (LOF Files - Audacity Manual)
and then “Align Tracks End to End” (Tracks Menu: Align Tracks - Audacity Manual)

Then, if you want them all in one track:
“Ctrl + A” (select All)
“Tracks menu > Mix > Mix and Render”

If you want to get fancy, I think the last three steps (after the import) could probably be automated with a macro (see: Macros - Audacity Manual)

This is a follow-up after trying your suggested method for concatenating multiple MP3 files.

  • The LOF documentation page specifies that for Windows, the path separator must be doubled in quotes. This is incorrect. The LOF file should not escape path separator characters. The documentation states:
file "C:\\Ken\\sample2.wav" offset 5   # sample2.wav is displayed with a 5s offset
file "C:\\Dave\\sample3.wav"           # sample3.wav is displayed with no offset

But if path characters are escaped, Audacity raises an error for each file name entry that must each be dismissed. When processing > 60 files, dismissing each message box is (at best) tedious. This could easily be resolved by recognizing Esc to break the file name parse error loop.

  • The LOF documentation page does not state how to use the LOF file. It’s as simple as File > Open. But unless you stumble over that in the File menu documentation page before encountering the LOF documentation page, it remains a mystery. A reference to File > Open on the ‘LOF Files’ documentation page would be helpful.
  • You recommended ‘to get fancy’, create a macro to automate the steps. I ran into a problem attempting to Select All tracks in the macro listed below.


Import2:Filename="D:\\Braille Library\\2021-04\\2021-04 Side_1.lof"
SelectAll:
Align_EndToEnd:
SelectAll:
MixAndRenderToNewTrack:
ExportMp3:

Thanks for your input.

Thank you for your report and comments.

I don’t think it says “must”. In fact, it seems to work equally well for me with a single-slash or with a double-slash, when I create the macro with Notepad.

Either way, with 3.0.0 and on 3.0.2RC on Windows, I get none of these message boxes.

Good suggestion. I have forwarded your suggestion to the documenters for review. Note the the manual for 3.0.2 is already closed, so any changes would not appear until 3.0.3 or later.

So I tried your macro. (You may want a simple “MixAndRender”, not “MixAndRenderToNewTrack”.) Regardless, the macro seems to die after the first command on 3.0.0 and on 3.0.2RC. However, if the first command is removed to a second macro, and the macros are run separately, they seems to do what you want.

I would like to see what steve has to say.

I can reproduce that on Windows 10.
It looks like the developers “fixed” the path separator on Windows without updating the documentation. The documentation will be updated, but it may be too late for the next Audacity release.

I fixed that for the upcoming next release 3.0.2 Manual this morning
https://alphamanual.audacityteam.org/man/LOF_Files

And I improved the Import page:
https://alphamanual.audacityteam.org/man/Importing_Audio#filetypes

The File Menu page Open section already mentions LOF files and links to the page:
https://alphamanual.audacityteam.org/man/File_Menu#open

Thanks for suggesting that - good catch :smiley: :sunglasses:

Peter.

The alpha documentation that we work on has always shown a single slash and not a double slash = tight from back in June 2011 when Bill created it.
https://alphamanual.audacityteam.org/m/index.php?title=LOF_Files&oldid=11916

And remains so in today’s latest version:
https://alphamanual.audacityteam.org/man/LOF_Files

I’m suspecting that the extra slash gets mysteriously added when the manual gets “pulled” for release.

Peter.

Looks like it.

It can be seen here too:

https://alphamanual.audacityteam.org/man/Preferences#stored

Windows: Users<username>\AppData\Roaming\audacity

https://manual.audacityteam.org/man/preferences.html#stored

Windows: Users\\AppData\Roaming\audacity\

Steve logged this in our bugtracker
https://bugzilla.audacityteam.org/show_bug.cgi?id=2744
Manual: Incorrect escaping of backslash character

Peter

I also just added a LOF files entry to the front page to aid “discoverability”
https://alphamanual.audacityteam.org/man/Main_Page#Help_with_Advanced_Topics

Peter.

Windows 10, Audacity 3.0.0

This error occurs for me on an entire batch of mp3s that open fine in 2.3.3.

Opening and resaving in mp3DirectCut does not help. I had to reencode these recordings to get them into Audacity 3.0.0.

The files in question were not created by merging other files or anything of that sort.

How were they created?
Do you have a small MP3 file that has this problem that you could share with us?

How were they created?
Do you have a small MP3 file that has this problem that you could share with us?

Thanks for your interest.

These recordings came to me as a commercial DRM-free audiobook I bought from one of Norway’s major booksellers, so I don’t know how they were made. Those originals—which I don’t have at hand—are in mono. I chopped them into slices with mp3DirectCut, which is supposed to be above blame, but maybe it introduced the problem. An example is attached.

mp3check reports:

2308 bytes of junk before first frame header

MP3 Diags reports:

Frame count mismatch between the Xing header and the audio stream.

Strangely, even after fixing both of those issues the file still fails to import. The file clearly has problems, but I’ve not yet found which problem is causing it to fail in Audacity.

Regardless of that, there’s an easy fix:

  1. “File menu > Import > Audio”
  2. In the import file browser, select “FFmpeg-compatible files” as the file type.
  3. Select the “audiobook 002-01.mp3” file.

If you then export as MP3 you will get a properly formed MP3 file that opens normally.

Thanks, although the easier fix has been to revert to 2.3.3. I forgot to mention that I had tried stripping off the header (on another copy of the file) with no luck.

I’m adequate with the Audacity interface, but am not deep enough in to know whether operations like the one you recommend can be automated. I could use ffmpeg to batch reencode all the files, if I find the older version of Audacity chafing, but your suggestion got me wondering about whether Audacity could be scripted or run from the command line to handle this.