Encoder Tag Changed After MP3Tag Updates

#1

I'm using mp3tag 2.52 and Audio Shell (www.softpointer.com) to view the encoder id. I have music stored in Flac format, which I currently convert to Lame 3.99. I then use mp3tag actions to update filenames, titles, comments, track, artist, discnumber, album & year, after which the encoder is changed from Lame 3.99 to FhG. The problem occurs even if I make my mp3tag changes to the Flac files first, then convert them to Lame 3.99 (most tags are duplicated in the Goldwave conversion), and then update a single tag, such as Artist or Discnumber.

I'm assuming only the encoder tag is changing, not the actual encoding of the file. This hasn't happened with all, or even most files, but when it does, it uniformly affects all files in an album. One album, containing 919 kbps flac files, does not have this problem, another, containing 1142 kbps flac files, does. Any mp3tag update, even changing a single character, results in the error, regardless of the Lame 3.99 bit rate. Adding an intermediate step of using Goldwave to do a flac to flac conversion did not change the results. Both sets of flac files use LibFlac 1.2.120070917, as does Goldwave.

While experimenting with files of different bit rates and Lame versions, I also found a file that was Lame 3.96 which had its encoder tag changed to Xing. However, my experiments seem to indicate it's mainly a problem with Lame 3.99 encoded files.

I first discovered this was happening with mp3tag v2.44.

EDIT: I tried to make test files, but I could not get the failing files under the 250k upload limit. I did notice that the file that does not produce the error also does not change size when updating with mp3tag. The test files that change to FhG encoder values after updating add 290 kb to the file sizes.

#2

use:

to upload and share your example files.

#3

Thanks. Here's the link to the files: http://www.mediafire.com/?puys4gzi93a19

There are three files: the original flac, the mp3 created from the flac, and the mp3 after updating with mp3tag (with the encoder tag changed).

#4

The problem is you have set Mp3tag to also write APE tags to the files. And because you have a big cover in the tag and APE tags are written at the end of the files, the other program does not find the encoder information anymore. Maybe it cannot handle APE tags (with pictures).

And your file has no lame header which would make is easier to detect the encoder. So maybe you need to check your encoding process why the lame mp3s have no lame headers.

And in general APE tags on mp3s should be avoided if there is no real need for them.

#5

Thanks very much for the quick reply. Unchecking the 'write' of APE tags fixed the problem. I'm assuming leaving the other APE checkboxes (Read, Remove) checked is appropriate. I guess I thought that the more tags that were written, the more flexible the files would be when dealt with by various programs. Guess not.

I don't have a clue about the absence of a Lame header. As I mentioned, I use Goldwave to convert files, and this is a pretty mature program (I've used it for 10 years). It uses standard lame_enc.dll. I know nothing about music file headers, but Mp3Diag does not indicate a missing header for the file ""01 - Test [1142-1322] [Before updating with mp3tag].mp3", which was created by Goldwave. Mp3Diag's only complaints are about an image not being loadable from the APIC frame, and no undo normalization information. Isn't all this tag information part of the Lame header?

closed #6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.