MP3packer—Can output be damaged by later processing? Different frame#?, [TOS #6: was “Practical question”/“Any change in sound-clip, ...”] Options

[crazyman]

Hi all,

pls
1. is it theoretically possible that after applying winmp3packer the file sounding perfect before may get some glitch or clip, when I apply then some other mp3 processing tools (mptrim, mp3val, ....)?


2. Very often I get the following message. "WARNING: Actual number of frames (7905) does not match the input info (7906)
Finished processing file"


Any comments and explanations are welcome.

This post has been edited by crazyman: Jan 29 2013, 00:08

[Dynamic]

Be aware that MP3 was standardised without some desirable features included and many desirable features had to be retrofitted without breaking backward compatibility.

Most modern VBR files (and many CBR files also) provide a helpful first header frame (silent so it doesn't affect old decoders that don't recognise it) to add features for decoders that do - namely improved seeking and gaplessness in VBR files, plus info about encoder settings. Some of the older tools may not be aware of it and may make other changes without reflecting those changes in the header frame, or corrupt it and may even trim it off automatically, being silent (but at least tagging tools don't corrupt it or move it to the end of the file, which is another reason to make it a silent MP3 frame at the start of the file)

Often the easiest way is to only use tools that recognise the VBR headers (mp3DirectCut works for me), but where you use something else, making a backup copy first then running the file through foobar2000's right-click/Utilities/Fix MP3 VBR header and Rebuild MP3 Stream will usually make things right again.

(I haven't used mp3trim or mp3val myself, but presume they're probably causing the problem)

This post has been edited by Dynamic: Jan 29 2013, 11:28

[testyou]

mp3splt is very good, also for ogg vorbis files.