Saving tags in Picard appears to alter the audio stream?

MusicBrainz Picard
1

So this is a weird one and I’m not exactly sure what’s happening so the topic subject may be wrong.

I have this m4a I converted from a flac, the flac and the m4a have a duration of 3:57.920 (10 492 272 samples) as reported by foobar2000. Plopping that m4a to picard and saving the tags on it alters the duration to 3:57.981 (10 494 976 samples). That’s obviously not a big difference, but whatever it’s doing is breaking the gapless playback between this and the next track.

And I would also think that tagging the file should not alter the audio duration at all. So it seems a bit odd.

correct duration
incorrect duration

2

Is this really a M4A file (that’s a MP4 container supposed to contain audio only) or is it a raw AAC file? What does the info dialog in Picard show for this file?

3

The main difference in the metadata seems to be that Picard removes some iTunes metadata (green boxes) and rewrite the MusicBrainz tag names slightly different (orange boxes):

image
image1971×1178 224 KB

But this should not be related to the audio stream itself, AFAIK.

1 Like
4

It most certainly should be a m4a. Picard says the format is MPEG-4 Audio (AAC LC). I used qaac (which uses the apple encoder) for flac to m4a conversion.

I should note that saving the tags in mp3tag for example is fine. But after picard does whatever it does, it doesn’t seem to be possible to revert the process.

5

Oh, seems I figured it out, removing the itunsmpb tag is what’s causing it. Adding it to the preserved tag list, refreshing the album and saving will keep the duration the same and retain gapless playback. Good shout @InvisibleMan78 about the itunes metadata.

Quick googling seems to suggest that the itunsmpb tag is indeed used for gapless. This might be a good tag to preserve by default I think.

6 Likes
6

I’m not familiar with/don’t use m4a, but please do open a ticket if you think this would be a improvement!

7

Are you using an outdated version of Picard?

8

I’m not too too familiar with it either and I’m also not entirely sure if the tag is m4a specific, but I made a ticket anyway, so we’ll see what happens.

9

Nope, and as far as I can see this has nothing to do with tagger script.

10

But “Clear existing tags” is most likely activated, hence the tag removal.

11

I’m not at home right now to confirm but very likely yes. Does clear existing tags also remove mp3 gapless info tag? I don’t remember encountering this there so I guess no? I’d propose treating this the same way, considering how destructive its removal can potentially be.