a duration field missing after editing tags?

[AaronRendahl]

After editing tags, I discovered that my m4a files play in most but not all applications; specifically, they don't play in the Quick Look Mac application, which is used to play files from the Finder file manager. They do play in (Mac) Music and VLC.

It appears the issue may be a missing duration field; after running the file through ffmpeg using passthrough filters, this duration field is back and it then plays in all applications.

I'm using tageditor from the command line on a Mac, with everything pulled from github a few days ago and compiled without the graphical interface. It's linked against: C++ Utilities: 5.20.1-1029.23ca577, Tag Parser: 11.5.0-762.93da1f1; I somehow can't find a version number for tageditor to confirm I have the most recent update.

Using mediainfo, there are two Duration tags before (one overall, one in the track) and only a "Source duration" tag after:

> mediainfo Crazy1.m4a | grep uration
Duration                                 : 2 min 35 s
Duration                                 : 2 min 35 s
> mediainfo Crazy2.m4a | grep uration
Source duration                          : 2 min 35 s

Using exiftool the "Track Duration" field is now missing

> exiftool Crazy1.m4a | grep Duration
Duration                        : 0:02:36
Preview Duration                : 0 s
Selection Duration              : 0 s
Track Duration                  : 0:02:36
Media Duration                  : 0:02:36
> exiftool Crazy2.m4a | grep Duration
Duration                        : 0:02:36
Preview Duration                : 0 s
Selection Duration              : 0 s
Track Duration                  : 0 s
Media Duration                  : 0:02:36

Using tageditor -if the two files are identical; both have two "Duration" fields (one for the container, one for the track) that all say 2 min 35 s 829 ms 115 µs 600 ns. (Since the tag editor also supports changing meta-data on track level such as the language of tracks it messes with tracks in the first place. Of course no data loss should occur due to that.)

[Martchus]

You're right. The absence of the duration in MediaInfo's "General" section can be easily reproduced:

ffmpeg -i test1.m4a  -c copy test-duration.m4a # create fresh file
tageditor-qt6 set --layout-only -f test-duration.m4a --output-files test-duration-edited.m4a
mediainfo test-duration.m4a # duration is present in the "General" section
mediainfo test-duration-edited.m4a # duration is not present in the "General" section (only in the "Audio" section)

Editing tags shouldn't have an impact like this so this is clearly a bug. Thanks for bringing it to my attention. I'll have to figure out what's being lost here.

[AaronRendahl]

Thanks for checking it out so quickly! Hope it turns out to be an easy fix. Thanks for the nice software, I've enjoyed using it so far.

…

On Sun, Jan 1, 2023 at 5:02 PM Martchus ***@***.***> wrote: You're right. The absence of the duration in MediaInfo's "General" section can be easily reproduced: ffmpeg -i test1.m4a -c copy test-duration.m4a # create fresh file tageditor-qt6 set --layout-only -f test-duration.m4a --output-files test-duration-edited.m4a mediainfo test-duration.m4a # duration is present in the "General" section mediainfo test-duration-edited.m4a # duration is not present in the "General" section (only in the "Audio" section) Editing tags shouldn't have an impact like this so this is clearly a bug. Thanks for bringing it to my attention. I'll have to figure out what's being lost here. — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3AIN4UKSCZWGJWN5MDWTDWQIEJRANCNFSM6AAAAAATOF4DYM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- -- Aaron Rendahl, Ph.D. Associate Professor of Statistics and Informatics College of Veterinary Medicine, University of Minnesota 300A VetSci, 612-301-2161

[Martchus]

Maybe it is an easy fix, indeed. The hard part will be figuring out where exactly the difference between the original and the edited file is. The mp4file utility from bento4 shows the following:

cp test-duration.m4a test-duration-orig.m4a # backup the original file as --output-files doesn't work when the file is not rewritten (this is yet another bug)
tageditor-qt6 set --layout-only --max-padding 1024 --min-padding 0 --tag-pos back --force --index-pos back --force -f test-duration.m4a # keep original file structure as much as possible to ease diffing
mp4file --dump test-duration-orig.m4a > test-duration-orig.structure
mp4file --dump test-duration.m4a > test-duration.structure
# replace file name so it is the same in both outputs
colordiff -Naur test-duration-orig.structure test-duration.structure 
--- test-duration-orig.structure        2023-01-02 01:10:21.155805265 +0100
+++ test-duration.structure     2023-01-02 01:09:15.107806612 +0100
@@ -1,6 +1,6 @@
 "test-duration.m4a": Dumping meta-information...
  "test-duration.m4a": type ftyp (ftyp)
-  "test-duration.m4a": majorBrand = M4A
+  "test-duration.m4a": majorBrand = M4A 
   "test-duration.m4a": minorVersion = 512 (0x00000200)
   "test-duration.m4a": <table entries suppressed>
  "test-duration.m4a": type free (free)
@@ -25,7 +25,7 @@
     "test-duration.m4a": modificationTime = 0 (0x00000000)
     "test-duration.m4a": trackId = 1 (0x00000001)
     "test-duration.m4a": reserved1 = <4 bytes>  00 00 00 00  |....|
-    "test-duration.m4a": duration = 3007 (0x00000bbf)
+    "test-duration.m4a": duration = 0 (0x00000000)
     "test-duration.m4a": reserved2 = <8 bytes>  00 00 00 00 00 00 00 00  |........|
     "test-duration.m4a": layer = 0 (0x0000)
     "test-duration.m4a": alternate_group = 1 (0x0001)
@@ -51,7 +51,7 @@
      "test-duration.m4a": modificationTime = 0 (0x00000000)
      "test-duration.m4a": timeScale = 44100 (0x0000ac44)
      "test-duration.m4a": duration = 135189 (0x00021015)
-     "test-duration.m4a": language = Undetermined (0x55c4)
+     "test-duration.m4a": language = UNDEFINED(0) (0x0000)
      "test-duration.m4a": reserved = <2 bytes>  00 00  |..|
     "test-duration.m4a": type hdlr (moov.trak.mdia.hdlr)
      "test-duration.m4a": version = 0 (0x00)
@@ -150,7 +150,7 @@
     "test-duration.m4a": modificationTime = 0 (0x00000000)
     "test-duration.m4a": trackId = 2 (0x00000002)
     "test-duration.m4a": reserved1 = <4 bytes>  00 00 00 00  |....|
-    "test-duration.m4a": duration = 3000 (0x00000bb8)
+    "test-duration.m4a": duration = 0 (0x00000000)
     "test-duration.m4a": reserved2 = <8 bytes>  00 00 00 00 00 00 00 00  |........|
     "test-duration.m4a": layer = 0 (0x0000)
     "test-duration.m4a": alternate_group = 0 (0x0000)
…

So duration-specific information that is stored within the moov.trak.tkhd atom is missing. (The remaining diff is just because tag fields aren't written in the exact same order again. Not sure about the diff regarding the "majorBrand" info.)

This issue is possibly related to my latest changes I did to fix #80 (commit 503fb725a22bbe7e15199220b1d0e84fc6427170).

[Martchus]

This bug should be fixed on master (of the tagparser repository). Now the duration within moov.trak.tkhd should be preserved.

I've also noticed that a language value that is explicitly set to "und" (undefined) is turned into a null value. This should be fixed as well so "und" is preserved. (But a null value is also preserved. The track's language is basically kept unless one really wants to change it.)

[AaronRendahl]

That's great, thank you! Open source projects (with responsive authors and/or maintainers) are the best!

…

On Mon, Jan 2, 2023 at 12:53 PM Martchus ***@***.***> wrote: This bug should be fixed on master (of the tagparser repository). Now the duration within moov.trak.tkhd should be preserved. I've also noticed that a language value that is explicitly set to "und" (undefined) is turned into a null value. This should be fixed as well so "und" is preserved. (But a null value is also preserved. The track's language is basically kept unless one really wants to change it.) — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3AIN6YEPOGSUWHZWYCWL3WQMP3ZANCNFSM6AAAAAATOF4DYM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- -- Aaron Rendahl, Ph.D. Associate Professor of Statistics and Informatics College of Veterinary Medicine, University of Minnesota 300A VetSci, 612-301-2161

[Martchus]

It would be great if you could confirm whether this also solves the playback issues on that MacOS-specific player. (If not, I'll have to dig deeper.)

By the way, if you encountered any problems when building for MacOS, feel free to add/update possibly missing/outdated remarks to the documentation (either here or in one of the dependencies, like the README of c++utilities).

[AaronRendahl]

Yes, I'll try to do that, thanks for your quick work on this. It may be the weekend before I'll have a chance to rebuild and try it. I didn't run into any issues when building, it all pretty much worked. The only issue I remember in the documentation was that it wasn't immediately clear that all the packages were connected and that the primary build documentation was in another package. I'll see if I can put together a more specific suggestion when I build again.

…

On Tue, Jan 3, 2023 at 6:46 AM Martchus ***@***.***> wrote: It would be great if you could confirm whether this also solves the playback issues on that MacOS-specific player. (If not, I'll have to dig deeper.) By the way, if you encountered any problems when building for MacOS, feel free to add/update possibly missing/outdated remarks to the documentation (either here or in one of the dependencies, like the README of c++utilities). — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3AINYYQ66CENPDKQ4NKZLWQQNT3ANCNFSM6AAAAAATOF4DYM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- -- Aaron Rendahl, Ph.D. Associate Professor of Statistics and Informatics College of Veterinary Medicine, University of Minnesota 300A VetSci, 612-301-2161

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.