MP3 conversion glitches

Paul-Fegan wrote on 8/8/2025, 9:03 AM

I've been using various version of SF to convert to MP3 for years without issue. Usually, I was batch converting files for elearning to 128 kbps MP3s. But recently, I had to batch convert some WAVs for an audiobook. The WAVs all meet the ACX specifications (as tested in SF18), but this time, I need to convert to 192 kbps. The problem is that it's introducing random audio glitches. You could batch the same file twice and the glitches wouldn't necessarily be in the same place. Has anyone else encountered this? I could export to a higher bitrate like 320, but Audible says it's unnecessary and I'd rather just meet the spec. I'll do it, though, if the files are glitch free and I've no other option.

So does anyone know if conversion from 44 kHz, 16 bit, mono WAV to 192 kbps MP3 should cause a problem?

Many thanks.

Comments

SP. wrote on 8/8/2025, 9:22 AM

@Paul-Fegan If you open the Sound Forge program preferences while holding the SHIFT key, there will be an additional Internal tab available. There you should be able to activate the legacy MP3 encoder. This one might work better.

Paul-Fegan wrote on 8/8/2025, 9:25 AM

Oh cool. Thanks, SP. I shall give that a go. I notice in older version of SF (13 and earlier), it would only allow a bitrate of 128 kbps if your file was mono, which audiobook files tend to be. I'll see if this is the case when I try the legacy encoder. Thanks again.

rraud wrote on 8/8/2025, 9:37 AM

does anyone know if conversion from 44 kHz, 16 bit, mono WAV to 192 kbps MP3 should cause a problem?

Hi @Paul-Fegan, what version of SF are you using?
The later versions of Sound Forge has a (hidden) option to use the legacy MP3 encoder or the 'newer' (default) encoder which some parameters like 'joint stereo' cannot be disabled... though I have not experienced any encoding issues regardless if the source file is mono or stereo and/or is encoded in mono or stereo. I would recommend single-channel mono for spoken word projects since there is typically no spacial (stereo) information like music or S/FX, Plus encoding a mono MP3 will double the resolution at the same bitrate and file size as stereo and still meets ACX specs.

Paul-Fegan wrote on 8/8/2025, 9:49 AM

Hi Rick, I'm using SF18, but am trying this in SF14 now, too. I've just encoded one chapter on its own in SF14 and so far, it seems OK. But it's so random that one file could be fine and another might have glitches. And yes, as mentioned, I'm converting a 44 kHz, 16 bit, mono file as it's just voice, so no stereo files are involved.

I'll convert another file in SF14 and if it works OK, I'll try them all. If it fails, I'll try the legacy encoder you and SP mentioned. Thanks a mill.

Paul-Fegan wrote on 8/10/2025, 6:49 AM

Actually, correction. I used SF18 to edit the WAVs, but with the new batch converter being terrible, I used SF14's Batch Converter to create the MP3s. Looking into it, this means I used the LAME encoder. Interestingly, I was getting the same results with REAPER and the VLC Player's converters, both of which use LAME. And this was across two different PCs, too.

I'm now listening to the MP3s from a third PC's batch conversion, but still using SF14. So far, no glitches, but I'm only a few files in, so they could still present themselves yet.

I have never had problems with MP3s in any software so the only thing that's new to me is that I'm converting to 192 kbps. So I wonder if it's an issue with LAME encoding 192 kbps MP3s. This is for Audible and 192 is what they want, but they say you can go higher, so I might see if encoding to 320 is better and Audible themselves can convert it back to 192.

After 25 years, I never thought I'd be grappling with MP3s! 😄

rraud wrote on 8/10/2025, 11:31 AM

Hi @Paul-Fegan, are sure it is an encoding issue.. It could be the player (decode) causing the glitches? Open the MP3 file in Sound Forge and look for glitches in the waveform.. though they may be difficult to spot in a spoken word file, but you could test encoding a sine wave (aka, test tone),
Try encoding in the CBR (constant bit rate) mode, I have read of VBR issues, but I do not recollect the manifestation.
There is no particular reason, but I rarely encode at 192 kbps and usually encode at 128, 256 or 320 kbps for music projects depending on the desired file size. I have used 192 kps on occasion though and do not recall any issues using Sound Forge or the standalone 'WinLAME' RC3 encoder.. which I use a lot since it has some useful parameters like HP/LP filters, ect., (editing the preset file code). WinLAME RC3 can also batch convert and is very fast,
Can you share a file on Google Drive, Dropbox, WeTransfer or other, so we investigate first hand?

Paul-Fegan wrote on 8/10/2025, 12:07 PM

Hi Rick, the proofer who was listening to the files first reported it on her machine and when I checked the files on my machine (different countries), she was right. The anomalies didn't appear in the WAV files, just the MP3s after conversion. Also, if you convert the same file multiple times, the glitches are in different places, or there may be none at all. Sometimes you get a few glitches close together, sometimes just 3 spread out over a 30 minute file.

The only reason I'm using 192 kbps is because that's Audible's spec. However, I could convert to a higher bitrate if required and Audible will reduce it to 192 on their side. 320 might be less problematic for me; I haven't tried it yet.

So now I've done a fresh batch on a different machine with SF14. I then checked 4 random files completely and found no glitches. After that, I listened to the first 10 mins of the remaining chapters (audiobook) and they were fine. So I've sent these new conversions back to the proofer. Fingers crossed. I'm happy to post segments if they appear again, but they sound just like a static glitch or a spike in the audio. Like the lifting of a record needle/stylus. Unmistakably bad.

LAME is allegedly better than Fraunhofer, but these issues appeared after conversion to 192 using different machines and different software, all of which are using LAME. In SF14, I set the quality to highest and unchecked the VBR box, so I'm guessing that means CBR. However, Fraunhofer is allegedly better for CBR.

If this latest batch works, I'll be mystified as to why because it was another SF14 batch using LAME.

Here's a wildcard, though: occasionally, when fixing problems in the main WAVs, I'd bring them into RX11, repair them and press Save. I wonder if that was altering those WAVs in any way that might cause them to glitch when rendered to 192 kbps MP3s. I can't think why, but I'm stumped with this one.

Thanks for the reply.

rraud wrote on 8/10/2025, 2:46 PM

What are the general length/duration) of the files you are encoding Paul .. if that makes any difference? What are the attributes of the master PCM (wave) files, so I can try to duplicate the behavior. A MediaInfo readout would be good. If you do not have MediaInfo already, you can download it here. Most versions of MPC (Media Player Classic) has MediaInfo integrated as well. I am not sure if VLC can generate a media report.

Paul-Fegan wrote on 8/10/2025, 5:56 PM

The lengths vary, Rick. They could be as little as a few seconds (opening credits) to just over an hour (a long chapter). I exported the recorded audio as WAV from REAPER (been doing that for years and nothing's changed on that end) and then edited them in SF18 (most of my previous work would have been edited in SF14). So SF18 is new to the equation, although I'm still saving as a standard Wave (Microsoft) .WAV in SF18, in a 44 kHz, 16 bit, mono, PCM format. I'll install that software you mentioned and check the info you requested in the morning.

So I suppose the new elements here are SF18 and converting to 192 kbps MP3. I have been using SF18 for other projects for the past few months without issue, but I was either delivering audio as WAV or 128 kbps MP3 — never 192 kbps.

All very strange and frustrating, and I can't wait to get to the bottom of it so I can restore my confidence in converting to MP3 again.

Thanks a mill.

Paul-Fegan wrote on 8/11/2025, 6:16 AM

Hi Rick,

Attached is a the media report for one of the files at random. Sorry, the forum won't allow a text file, so I had to take a screenshot.

By the way, according to a search I did, SF18 uses the Fraunhofer MP3 encoder, but SF18's Batch Converter uses LAME. Is this true? Two different encoders in SF18 depending on which method of conversion you use?

Many thanks,
Paul

rraud wrote on 8/11/2025, 1:20 PM

Hi Paul, I created a 45 minute, 44.1kHz, 16 bit, 400Hz mono PCM wave test tone file and encoded 192 kps, 44.1k, CBR mono MP3s from that. I encoded directly from the timeline and a second set from the batch converter. I used SFP-18's default MP3 encoder and the legacy MP3 encoder (enabled via the Internal menu). I also encoded another using my stand alone LAME MP3 encoder (WinLAME). I did not see glitches in any of the files in the Sound Forge wave forms. I spot check listened to all in Sound Forge, VLC, MPC and Windows default media player and did not hear any glitches either.. of course I did not listen to all the 45 min files end-to end or I would be more crazy than I already am.
Can you upload one of the 'glitched' files to a cloud drive so I can inspect it. If you are concerned about privacy, PM me the URL through this forum.

I would think encoding from the timeline or from the batch converter tool uses the same encoder which I assume is the Fraunhofer, I do not think Magix or SCS ever used LAME .. legality issues.,. which is why the LAME codec developers named it "Lame Ain't a MP3 Encoder"

Paul-Fegan wrote on 8/11/2025, 1:37 PM

Hi Rick, wow that's a lot of effort to see if you can reproduce this issue. I really appreciate the lengths you've gone to here.

Bizarrely, I don't think I have a glitched file remaining (I'll check the recycle bin) because once I identified the reported glitches, I re-ran the batches using other software, or using different parameters, and over-wrote the originals to make sure I didn't accidentally send them again. I sent off a new batch yesterday and the proofer/client downloaded it this morning. She's listening now and if she discovers any glitches, I'll isolate them and send them on. If not, then it means they're fine, but it'll mean that the Batch Converter in SF14 eventually worked, which won't make any sense. And it won't make me feel any more confident when batching in future.

By the way, when you ask AI which encoder SF14 used, it says LAME. I'm not sure where it's getting that idea from if it was always Fraunhofer, but of course AI is just scouring the net, so if someone posted that once in error, AI is just going to parrot it.

Incidentally, I see the ACX (Audible) guidelines recommend the following converter (see link below). Oddly, though, in their instructions, it recommends using LAME 3.99 or something. I downloaded the latest version of freac today and the encoder was LAME 3.11. I wonder why it's an earlier version than ACX's instructions showed.

https://www.freac.org/

OK, I'm off to trawl the recycle bin and see if I can find you a glitched sample. Thanks a mill.

Paul-Fegan wrote on 8/11/2025, 1:47 PM

Hi again, Rick. I found some deleted files in the recycle bin and restored one that I knew had glitches. I have taken a short excerpt here where two glitches appear: in the words "noob" and "mind you". Let me know if you can access the file.

Many thanks,

Paul

rraud wrote on 8/12/2025, 12:00 PM

I really do not know. Have you tried enabling the legacy MP3 encoder and trying that? Replacing the "mp3plug2.dll" file in the 'FileIO Plug-Ins' folder may fix the issue, I tried the <.dll> MP3 file from SFP-15 which worked, but I'm not sure that is the problem since I cannot duplicate the behavior and I did not experience any glitches in my sine wave file tests, nor have I read reports of this particular abnormality. As a work around, use a stand-alone LAME encoder. I am partial to the WinLAME RC3 UI as I previously stated,
i would like to inspect your PCM file and encode from that, if you can upload it to a cloud drive or WeTransfer, that would be good. Google and some others give you15GB of cloud drive storage for free, Mega.nz gives you 20GB free. Dropbox sucks IMO.

Paul-Fegan wrote on 8/13/2025, 4:44 AM

I'm stumped, Rick, because I've now used three PCs and not all even in the same location, and with different software: REAPER, Sound Forge 14 and VLC Player. Two with Windows 10 and the other with Windows 11.

I have a new PC at home using an old TASCAM US-144 MkII interface that I've had for years. Drivers are last dated 2014 and there are no new ones, but could this somehow encode the WAV files with something that would cause problems when encoding to MP3 later? It doesn't make sense, but nor does the fact I was experiencing issues on multiple PCs and with different software. Unless I'm just haunted. That might explain it.

I didn't try the legacy encoder in the end because I realised I was batching in SF14, which I imagine uses the same encoder?

The latest batch is still being proofed and so far, no news. But if this doesn't work, I'll try the encoder you mentioned and I might also encode to 320 kbps. I can't keep sending deliveries as the client/proofer has to keep listening to them all over and over again. I might just get an editor colleague to batch them for me next time. If that produces glitches, then there's definitely something spoooky going on with the WAVs. Maybe resaving them on another machine would help.

The deleted file I retrieved so I could send you a sample is on the PC at home. I'm happy to send it on to you for review when I get home. Can you drop your email address and I'll TransferNow it to you?

Thanks a million.

rraud wrote on 8/13/2025, 9:21 AM

If the same behavior occurred using SF-14, I don't think using the legacy MP3 encoder in SF-18 will help..
Where the master PCM (wav) file(s) rendered in Reaper.. then opened in Sound Forge for encoding?
Did you state the same issue occurred using a third-party MP3 encoder, bypassing Sound Forge all together?
Maybe try re-rendering another PCM (save as another PCM file. This is strange and I would like to find the cause

Can you drop your email address and I'll TransferNow it to you?

PM sent

Paul-Fegan wrote on 8/13/2025, 9:39 AM

Yes, I rendered from Reaper. And it was the first time I was rendering with live effects on the tracks. So here's the full audio journey:

1) recorded voice artist using Reaper; exported as 44 kHz, 16 bit, mono WAV (have been doing this for maybe 15 years)

2) opened in SF18 and edited (removing outtakes, reducing breaths, normalising... that type of thing); then saved file in same format (been doing this for 25 years)

3) reopened in Reaper and added some live effects (EQ, compression, limiter, etc.)

4) re-rendered as WAV and MP3 using these live effects (have never rendered VO with live effects before, but it's recommended)

5) WAVs were perfect, but MP3s had glitches

6) I reckoned Reaper (on a new high-spec PC, albeit with an old TASCAM audio interface) was maybe struggling to render with live effects AND encode to MP3 at the same time, so I reopened the latest WAVs in SF14 Batch Converter and batched them from there at 192 kbps, highest quality, CBR, etc.

7) MP3s had glitches, but in different files and at different places (very random)

8) Opened WAVs on PC 2 and encoded to MP3 using latest VLC Player. Still random glitches.

9) Opened WAVs on PC 3 and encoded to MP3 again using SF14. Awaiting news from proofer/client.

I think that's it, Rick, but do let me know if you have any questions. Many thanks.

rraud wrote on 8/13/2025, 11:59 AM

This leads me to believe it has something to do with the PCM (wave) files since glitching occurs outside of SF. Are both of your PCs using the same Tascam interface?
Did you say the issue occurs only when encoding @ 192 kps?

Paul-Fegan wrote on 8/13/2025, 12:07 PM

Well, it's strange because I'm using Reaper for 15 years without a hitch. I have encoded to 128 kbps on the new PC and didn't hear of any problems from clients (I tend to batch the files and send them off in a fire and forget sort of way).

The interface in the studio is a Focusrite 18i8 3rd Gen. On the third PC, which is just used for script display and comms, it's just a built-in Realtek thingy.

If there's a problem with the WAV files, I wonder could they be resaved in another WAV format and then encoded to mp3?

I'll send you one of the WAVs shortly, Rick. Thanks.

Paul-Fegan wrote on 8/13/2025, 12:19 PM

Rick, here are the Reaper WAV render settings. They should be default as I haven't altered them since installation on the new PC. Unless the devs, Cockos, did with this version. I tend not to change the WAV settings in any application and they haven't previously caused any issues.

Paul-Fegan wrote on 8/14/2025, 3:43 AM

Rick, something else occurred to me. After I'd edit the WAVs in SF18, I'd mark up any extraneous noises I wanted to get rid of, then take the files into RX11 Advanced. Here, I'd remove them. But I noticed a strange anomoly on this new PC that I've never noticed before: if you YouTube is playing quietly in the background when I moved from SF18 to RX11 Advanced and then I press PLAY in the latter, the pitch of YouTube in the background drops by 2 or 3 semitones. Once I'm finished in RX11, I have to press PAUSE and PLAY again in YouTube for the pitch to return to normal. So I wonder if RX11 is doing something screwy to the files, or at least the parts where I'm using Spectral Repair. I have looked at RX11's device settings and couldn't see anything abnormal, so just related it to the outdated TASCAM interface drivers.

However, this is all before I bring the files back into Reaper to re-render for the final time with the LIVE plug-ins, so you would think that would right any potential wrongs. Bear in mind that the glitches aren't present in the WAVs. Anyway, just thought I'd throw that spanner in the works. 😁

rraud wrote on 8/14/2025, 9:17 AM

Hi Paul, I do not think iZotope's RX would be the cause.
I see in the Reaper render settings screenshot, both Wav64 and BWF are selected, I wonder if one or the other could be causing the issue. Wave64 would be warranted for PCM files exceeding 4GB, so you likely do not need it.. (a 44.1k/16 mono PCM file is approx 300 MB per hour). A Broadcast Wave File has additional metadata for Time Code, sound reports, ect., which is also not necessary in this case.

Paul-Fegan wrote on 8/14/2025, 12:04 PM

Hi Rick, thanks for that. I think it's unlikely that the Reaper setting you mention is causing trouble simply because this is a default settings page. I checked my PC in the studio (which is older and has been well tried and tested) and the WAV render settings are the same. It's recorded tens of audiobooks and other projects without issue, which would have been edited by me and various other third-party post-production people.

I just typed this question into Google:
"can bad audio drivers cause problems when rendering audio?"

And the AI response was as follows (so this might be the issue — I need a new interface pronto):
"Yes, bad or outdated audio drivers can absolutely cause problems when rendering audio. These problems can range from minor glitches and distortions to complete failures in audio playback or rendering. 

Here's why:

Driver Compatibility:

Audio drivers act as the intermediary between your operating system and the audio hardware (like your sound card). If the driver is outdated, incompatible with your system or the software you're using (like a Digital Audio Workstation or DAW), it can lead to communication errors and rendering issues. 

Sample Rate and Bit Depth Mismatch:

Different audio devices and drivers may support different sample rates and bit depths. If the driver isn't configured to match the audio being rendered, it can result in errors. 

Performance Issues:

Outdated drivers might not be optimized for performance, leading to increased CPU usage, latency, or even crashes during rendering. 

Rendering Errors:

Specific errors like "Audio Renderer Error" can be directly caused by problems with the audio drivers, including issues with device recognition, buffer overflows, or processor overload. 

Software Conflicts:

Malware or other software conflicts can interfere with the audio driver's functionality, causing rendering problems. 

Hardware Problems:

In some cases, hardware problems themselves can manifest as issues with the audio driver, requiring troubleshooting steps like updating or reinstalling the driver. 

To address these issues:

Update Drivers: Regularly check for and install the latest audio drivers from your sound card or computer manufacturer's website. 

Check Device Settings: Ensure the correct audio device is selected in your operating system and within your audio software. 

Restart Services: Restarting the Windows Audio service or related services might resolve temporary issues. 

Try Different Drivers: If the problem persists, try using a generic driver or drivers from the manufacturer to see if it resolves the issue. 

Scan for Malware: Run a malware scan to rule out any software interference. 

Check Connections: Make sure all audio cables and connections are secure. 

Consider BIOS Updates: In some cases, updating your computer's BIOS can resolve hardware communication issues."

rraud wrote on 8/15/2025, 9:18 AM

That may very well be the cause and is the common denominator if it occurs on multiple PCs.