Bug Found in MP3 Rendering

Mohammed_Anis wrote on 7/17/2019, 2:25 AM

A reddit user and I may have just confirmed a bug in VEGAS PRO when it comes to rendering MP3.

Try importing any audio of your choice and render it as MP3, then import it back and zoom in.

You'll notice an ever so slight delay in the result. The rendered track is 0.5 second longer then the original.

This could be really annoying when you want to render out audio files that you want to re-import for looping.

Have tried WAV - the result is perfectly fine.

 

Comments

EricLNZ wrote on 7/17/2019, 3:05 AM

How long was your track that rendered half a second longer?

I've always understood that mp3 is not suitable for accurate editing due to the nature of its compression so I'm not surprised.

j-v wrote on 7/17/2019, 3:32 AM

The rendered track is 0.5 second longer then the original.

That difference I don't see.
When I render the highest possible mp3 out of an exactly13 min 57 sec Wav file I get a mp3 with a difference that is normally not visible but max inzoomed on the timeline the difference is 0,023 sec, look

Last changed by j-v on 7/17/2019, 3:33 AM, changed a total of 2 times.

met vriendelijke groet
Marten

Camera : Pan X900, GoPro Hero7 Hero Black, DJI Osmo Pocket, Samsung Galaxy A8
Desktop :MB Gigabyte Z390M, W11 home version 24H2, i7 9700 4.7Ghz,16 DDR4 GB RAM, Gef. GTX 1660 Ti with driver 566.14 Studiodriver and Intel HD graphics 630 with driver 31.0.101.2130
Laptop  :Asus ROG Str G712L, W11 home version 23H2, CPU i7-10875H, 16 GB RAM, NVIDIA GeForce RTX 2070 with Studiodriver 576.02 and Intel UHD Graphics 630 with driver 31.0.101.2130
Vegas software: VP 10 to 22 and VMS(pl) 10,12 to 17.
TV      :LG 4K 55EG960V

My slogan is: BE OR BECOME A STEM CELL DONOR!!! (because it saved my life in 2016)

 

Satevis wrote on 7/17/2019, 3:54 AM

Since mp3 stores audio data in blocks, it can't represent arbitrary audio lengths and you can expect the length of the mp3 to be "rounded up" compared to the wav file (which is a raw format with single-sample precision). This would not explain a half second difference but can certainly make mp3 unsuitable for storing loops or other audio fragments that need to line up perfectly.

Mohammed_Anis wrote on 7/17/2019, 6:53 AM

Thank you guys.
 

Since mp3 stores audio data in blocks, it can't represent arbitrary audio lengths and you can expect the length of the mp3 to be "rounded up" compared to the wav file (which is a raw format with single-sample precision). This would not explain a half second difference but can certainly make mp3 unsuitable for storing loops or other audio fragments that need to line up perfectly.

This perhaps explains everything.


I've done a few other mp3 files and got some variations after this thread on another PC.

I suppose its simply the nature of the codec

Ah well. False alarm.

 

Musicvid wrote on 7/17/2019, 8:50 AM

I believe it's a metadata chunk. It's the reason we don't use mp3 for loops.

rraud wrote on 7/17/2019, 10:08 AM

As MV and Satevis stated, this is inherent behavior with the MP3 encode/decode... always has been. Aside from the lossy quality issue, that is another reason audio folks avoid MP3s until the final end user delivery if needed.

Musicvid wrote on 7/17/2019, 1:02 PM

Never was a delivery format for video -- and its a kludge in those that do.