tone: Dump is writing errors to stdout

This is how I was writing custom metadata to m4b files using ffmpeg, which I found out was NOT a good idea. I will outline it here to show how tone dumps the file, I am not expecting tone to correctly parse this.

First writing a custom tag to the sample m4b here

ffmpeg -i .\samples\test_m4b.m4b -metadata ASIN="1337" -movflags use_metadata_tags .\samples\output_m4b.m4b

Ffprobe format output:

ffprobe -i .\samples\output_m4b.m4b -show_format -print_format json

    "format": {
        "filename": ".\\samples\\output_m4b.m4b",
        "nb_streams": 2,
        "nb_programs": 0,
        "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
        "format_long_name": "QuickTime / MOV",
        "start_time": "0.000000",
        "duration": "211.302000",
        "size": "1934997",
        "bit_rate": "73259",
        "probe_score": 100,
        "tags": {
            "minor_version": "0",
            "major_brand": "mp42",
            "compatible_brands": "mp42isomndia",
            "gapless_playback": "1",
            "track": "5",
            "genre": "abs",
            "artist": "advplyr",
            "title": "Test 5",
            "album": "node-tone",
            "comment": "testing out tone metadata",
            "album_artist": "advplyr",
            "composer": "Composer 5",
            "date": "2022-09-10",
            "ASIN": "1337",
            "compilation": "0",
            "media_type": "2",
            "encoder": "Lavf58.73.100"
        }
    }

Now tone dump

tone dump .\samples\output_m4b.m4b --format json

Output:

Unrecognized metadata format
   at ATL.AudioData.IO.MP4.readTag(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.readUserData(BinaryReader source, ReadTagParams readTagParams, Int64 moovPosition, UInt32 moovSize)
   at ATL.AudioData.IO.MP4.readMP4(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.read(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.Read(BinaryReader source, SizeInfo sizeInfo, ReadTagParams readTagParams)
   at ATL.AudioData.AudioDataManager.read(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.AudioDataManager.read(BinaryReader source, Boolean readEmbeddedPictures, Boolean readAllMetaFrames, Boolean prepareForWriting)
   at ATL.AudioData.AudioDataManager.ReadFromFile(Boolean readEmbeddedPictures, Boolean readAllMetaFrames)
Unrecognized metadata format
   at ATL.AudioData.IO.MP4.readTag(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.readUserData(BinaryReader source, ReadTagParams readTagParams, Int64 moovPosition, UInt32 moovSize)
   at ATL.AudioData.IO.MP4.readMP4(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.read(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MP4.Read(BinaryReader source, SizeInfo sizeInfo, ReadTagParams readTagParams)
   at ATL.AudioData.AudioDataManager.read(BinaryReader source, ReadTagParams readTagParams)
   at ATL.AudioData.AudioDataManager.read(BinaryReader source, Boolean readEmbeddedPictures, Boolean readAllMetaFrames, Boolean prepareForWriting)
   at ATL.AudioData.AudioDataManager.ReadFromFile(Boolean readEmbeddedPictures, Boolean readAllMetaFrames)
{
  "audio": {
    "format": "Unknown",
    "formatShort": "Unknown",
    "channels": {
      "description": "Unknown"
    },
    "frames": {},
    "metaFormat": []
  },
  "meta": {
    "title": "output_m4b"
  },
  "file": {
    "size": 1934997,
    "created": "2022-09-18T16:20:03.2173223-05:00",
    "modified": "2022-09-18T16:21:28.9052672-05:00",
    "accessed": "2022-09-18T16:26:33.0977549-05:00",
    "path": "\\NodeProjects\\node-tone\\samples",
    "name": "output_m4b.m4b"
  }
}

The issue is that tone is outputting all of this to stdout so node-tone is unable parse the JSON of the metadata that was found. It is okay that tone didn’t pull the ASIN tag, but I still want to get the rest of the output.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 20 (13 by maintainers)

Commits related to this issue

Added try catch for tag and dump command to prevent exceptions in stdout (#26) — committed to sandreas/tone by sandreas 2 years ago
added #26 to release notes — committed to sandreas/tone by sandreas 2 years ago
fix / workaround #26 - no longer dump exceptions to stdout — committed to sandreas/tone by sandreas 2 years ago

Most upvoted comments

Ok, since there was no release of atldotnet yet, I decided to give 0.1.1 a go… Could you please try if this fixed your issue?

Explanation:

exit code now should be 4 on errors while reading metadata
console is no longer polluted with errors
to see error details you can use --debug, --log-level and --log-file (which has to be documented in the near future)

Using --debug should create a logfile in YOURTMPPATH/tone.log or you specify the location e.g. via --log-file=/home/sandreas/tone.log. You can also use --log-level=debug, but the --log-level option is more meant for future usage.

sandreas on Oct 7, 2022

I think you might be right… (see https://github.com/mifi/lossless-cut/issues/402).

Basically this is why I wrote tone… because ffmpeg just can’t handle some metadata. Therefore, in m4b-tool I manage all metadata by myself including the following steps:

Reading out all metadata of all files to merge (here I use tone but in the past I used a combination of a PHP class and ffmpeg)
Recalculating metadata (track 1 of 10, Disk 1 of 2, sort title, movement-name, etc.)
merging the file with ffmpeg ignoring all source metadata
tagging the file with the recalculated metadata (with tone or mp4tags)

This is a huge effort but it is accurate, while ffmpeg produces bogus files every now and then… (e.g. concat filter produces an empty file, if the listing.txt contains only one file…)

So to conclue this issue, my todo:

Prevent tone from polluting stdout / stderr with error messages from invalid files
Return a unique errorcode, if the file could not be dumped or tagged

sandreas on Sep 26, 2022

Ok, I found a problem in atldotnet - the audio lib of tone. Usually the repo owner is very polite and quick with fixes, so I would like to wait until it is gonna fixed “the right way”, but I also already commited a workaround to prevent this. If the lib cannot be fixed in an acceptable time period, I’ll go for the workaround in v0.1.1.

sandreas on Sep 24, 2022

Thank you, reproduced. I’ll try what I can 😃

sandreas on Sep 24, 2022