I would still like to encode one of your PCM files and see what happens on my system. In an case, I hope the new interface resolves the issue.

Please do, Rick. It'd be very useful to know if the WAVs are somehow inherently flawed and causing the glitches during the MP3 encoding process. Then I'll have to wonder at what stage the flaws occurred: during initial clean up in SF18, or later during export with live effects in Reaper. Can't wait to get the new interface now and hopefully that will be the end of the trouble. Cheers.

Hi Rick,

Just thought I'd pop back here with a few updates:

1) firstly, the last batch of audiobook files I sent the client were fine (phew), but I'm not sure why. I batched them with SF13 or SF14 Batch Converter

2) I bought and installed a new interface on my home PC: a Focuerite 2i2 4th Gen

3) tonight, a voice actor asked if she could have a clip from an audiobook I recorded last year, but which was edited by someone else. So I downloaded one of the master audio files from the publisher's server (a 192 kbps MP3) which was pristine. I isolated a 60 second clip, trimmed it and hit SAVE (now saving over the original file). In SF18, this resaves it and retains the 192 kbps MP3 format. When I played it back, there was a glitch (see attached photo). I tried this whole process twice more using different parts of the original MP3 and there was a glitch in each one!

4) I opened the same original pristine 192 kbps MP3 in SF14 this time. Now, if you change something in SF14 and hit save, it saves it as a 128 kbps MP3. I had forgotten this, but I played back the 128 kbps file anyway and it was fine. But I wanted to test SF14 resaving as a 192 kbps clip. So I started again with the original 192 kbps chapter file. I isolated a clip and this time, clicked Save As. I then set it to save as a 192 kbps MP3. I played it back and it was perfect. So in case it was just by chance, I started all over again and did the same thing, creating a new 192 kbps MP3 file. It was also perfect.

So my conclusion now is that if I open a 192 kbps file in SF18, edit it and click Save (which should leave it as a 192 kbps MP3), it's going to glitch at random. So I'm now thinking that the problem is with SF18. Can anyone else test this for me? Find an MP3 that's mono, 44 Khz, 192 kbps, delete anything from it (just so it will allow you to resave the file) and then click Save. Then audition the file to see if it has glitched.

Many thanks,

Paul

@Paul-Fegan In our experience it's not a good idea to edit MP3 files. They are already lossy compressed, this means they are missing data compared to the original WAV files, and they are read out in frames of data instead of individual samples, which can throw sample accurate editing in Sound Forge off. You can easily see this, if you zoom in and out and the playback cursor goes all over the place. It's always a good idea to convert compressed audio files to WAV before editing them. There is also an option in the program preferences to always proxy compressed audio formats, which does basically the same.

Thanks, SP and I hear you. But my worry here is that if I edit it a WAV and need to save it to a 192 kbps MP3, that SF18 is doing something screwy with it that isn't happening in (for instance) SF14. It was displaying other really strange behaviour, too. For example after the file glitched, my selection was no longer snapping to zero but was snapping some distance away from zero. Also, I couldn't properly zoom in on the glitched area; it would zoom in to the right or left of the glitch. Also, I didn't even have to save the file for it to present with glitches. Since I last posted this evening, I noticed that if I did anything to the file, such as auto trim/crop, the glitch could appear immediately, before I even saved. I can't replicate these errors in SF14.

So while I don't typically edit MP3s at all (tonight I was just grabbing an excerpt for a friend), the fact SF18 is causing glitches is really affecting my confidence because I'm wondering if this is the only situation where it will glitch. I can't afford to risk sending clients dodgy files that I've batched or whatever.

But I'd still love to know if anyone else can replicate the behaviour because that would at least rule out a hardware or corrupted software issue.

Thanks a mill for the response.

Hi again Paul, which MP3 encoder are you using in SFP-18? The 'new' default encoder or the legacy encoder which must be enabled in the (hidden) 'internal' menu to access it.
I will try encoding @192kps/44.1k with both the SFP-18 encoders to check for glitches again.
As @SP. stated, always enable 'Proxy uncompressed formats' when working with MP3s.

So the new Focusrite interface did not resolve the issue? So we can eliminate the interface as the cause?

I couldn't properly zoom in on the glitched area; it would zoom in to the right or left of the glitch.

Disable 'Snapping' in the 'Options' menu.
I keep 'Snap to Zero crossings' enabled most of the time when editing, except to view an exact point in the waveform or using the pencil tool (down to the sample level).

Thanks, Rick. Yes, unfortunately, we can definitely eliminate the audio interface as the cause.

Good point. @SP. mentioned the legacy encoder earlier in this thread, but I hadn't tried it yet as I was getting errors in other applications, too. Or so I thought. I'm doubting everything now. I think the problems started in SF18 now and caused problems elsewhere. But I'm going to enable the legacy encoder right now and see if that solves the problem.

I always use Snap to Zero for editing, too, so that I don't wind up with self-created glitches. But I've never had this issue with zooming, despite having Snapping enabled. I can always zoom in on any point I want. With these glitches, though, they're so odd in that SF was almost not recognising the fact they were there and wouldn't allow me to zoom in on them, even though I could see and hear them. As in, they'd kind of disappear and would be quite far to the left or right of where I'd zoomed. It wasn't just because the glitches were above zero.

Incidentally, another reason I'd want to open a 192 kbps MP3 and re-save it is this: when I edited the WAVs, I ran the ACX checker to make sure the RMS and peaks were within limits. Once they were, I possibly used Save As (because I didn't like the new Batch Converter) to save the file as a 192 kbps MP3. But at this point, when I'd run the ACX checker again, I'd find that the peak level of some files had suddenly risen above -3 dB, so I'd have to run a limiter again and resave. So, just an example of a situation where I'd have to work on specifically the MP3 and resave it.

Anyway, I'm still not ruling out this new PC being haunted. 😁

OK, I'll try the legacy encoder and get back shortly. May take a few conversions because it's intermittent anyway.

OK, so here's what I've done:

1) in SF18, enabled Legacy MP3 encoder

2) opened a pristine 192 kbps audiobook file that was edited a year ago by someone else

3) selected 1 minute of audio, played it through — no errors

4) ran Trim/Crop just to cut away all audio outside of the selection, then played it through again - no errors

5) ran Auto Trim/Crop, then played it through again — 4 errors/glitches

So, I hadn't even resaved the file. Just running normal processes seems to (at random), induce glitches. I think I'm going to have to raise this with MAGIX. Audiobooks need to be converted to 192 kbps for Audible and I need to be able to convert with confidence and not have to listen back to every single chapter I convert. I wonder if reinstalling SF18 would fix it? Seems unlikely, but maybe worth a try. And I haven't noticed this with 128 kbps MP3s, though admittedly, I haven't run extensive tests.

UPDATE: it happens with 128 kbps MP3s, too, so I suspect it's MP3 of any kind

Hi @Paul-Fegan, Did you 'save' or 'Save as' the PCM file prior to encoding the MP3?

If you do reinstall SFP-18, I would first try "Reset all preferences and clear cached data" in SF's 'File' menu. If that does not help and you plan to uninstall/reinstall SFP-18, I would recommend using a third-party uninstaller like 'Revo Uninstall' that can uninstall and remove the left-over registry entries and other pertinent data the OS uninstall leaves behind, which can cause issues to reoccur.. Revo Uninstall has a pro and freeware versions. The free version is adequate in most cases, I always use Revo's 'Advanced' scan mode, but care should be taken not to delete shared data if you have another version of SF or Vegas installed. The scan process will generate a list of entries with file paths to help ID files from the other versions of SF that are on the PC.,, though a worst case scenario would only be accidentally removing an FX plug-in or preset.
If all else fails, contact Magix tech support (though it may take awhile to get a response with the current shake-up going on).