Closed advplyr closed 1 year ago
Ah, this pretty much relates to #25... there should never be an exception printed out, especially when dumping data. Errors have to be handled very carefully and robust.
So, I tried to follow the steps creating a bogus m4b
file via:
ffmpeg -i without_id3.m4b -metadata ASIN="1337" -movflags use_metadata_tags with_id3.m4b
and it failed to create a file. Would you mind providing a test file, that leads to this error, so that I can reproduce the issue directly?
So now I added a simple try catch block to prevent these errors in stdout, but I have to verify, that this fixes your problem - so an example file would be awesome.
The try catch is targeted for v0.1.1
I just committed a sample m4b with bad metadata here: https://github.com/advplyr/node-tone/tree/master/samples
tone dump .\samples\m4b_bad_metadata.m4b --format json
Will produce the error
Thank you, reproduced. I'll try what I can :-)
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
.
I want to add that when I write ASIN as an additional field in tone to an m4b file it won't show when doing an ffprobe. When I write ASIN to an mp3 file it does show when doing an ffprobe. Is ffprobe not able to parse additional fields for mp4 files?
Is ffprobe not able to parse additional fields for mp4 files?
I think so. If you have a sample m4b
file, where it does show an ASIN, you can analyse it with tone
, it is something like this: ----:com.audible:ASIN
.
I use ----:com.pilabor.tone:AUDIBLE_ASIN
(my own custom specification).
I can't get an m4b file to show the ASIN in both ffprobe and tone. Tone won't read the ASIN embedded by ffmpeg and ffprobe won't read the ASIN embedded by tone.
You can add a new issue for this with an example file, if you like. I don't think, that ASIN is a specified Tag in any well known format, but I'm definitely willing to investigate this.
mp3
/ id3
it is probably TXXX
(https://community.metabrainz.org/t/aac-and-alac-file-tagging-question/504352/4, https://id3.org/id3v2.3.0#Text_information_frames) or just ignoring the specs.mp4
there is officially no specified ATOM for ASIN
, so I don't know how ffmpeg
solves thishttps://gist.github.com/coolaj86/965870/9a0ad076fddd9a2ae0ab4eddc2ab1a3dc222d50a
I think ffmpeg is writing custom id3 tags into mp4 files which is why this causes problems with tone.
I thought this would be the case and wouldn't consider it an issue with tone or ffmpeg just this argument in ffmpeg movflags use_metadata_tags
is the problem.
I think ffmpeg is writing custom id3 tags into mp4 files which is why this causes problems with tone.
If that is the case, ffmpeg
in my opinion does the wrong thing.
What you could also try:
ffmpeg -i input.mp3 -movflags use_metadata_tags -metadata ASIN=B01M1KJCQB outfile.m4a
ffmpeg -i input.mp3 -movflags use_metadata_tags -metadata "----:com.apple.iTunes:ASIN=B01M1KJCQB" outfile.m4a
Is the file you provided generated this way? If so, I could talk to the atldotnet
expert about what is not ok in this file and if he would be able to ignore this case without acting against every spec :-)
I'm not sure if ffmpeg is doing the wrong thing or I am just using it incorrectly with that -movflags
argument.
I just tested what you mentioned and it causes the same error in tone as I mentioned in the OP. I think it is safe to say that -movflags use_metadata_tags
should not be used with mp4 files and this is not a problem with altdotnet/tone.
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:
tone
but in the past I used a combination of a PHP class and ffmpeg
)ffmpeg
ignoring all source metadatatone
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:
tone
from polluting stdout
/ stderr
with error messages from invalid filesOk, 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:
--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.
Is there a way to get an error message in stderr or stdout?
node-tone is always going to be using the json format. I can now correctly identify it failed using the error code but I won't be able to get any error message to the user without it coming through stdout or stderr.
As far as what you mentioned for this release my tests are all working as you described.
Is there a way to get an error message in stderr or stdout?
You mean putting the error to stderr and the dump output to stdout? Well, that would be possible... I thought putting the error to the logfile on demand (--log-level
) would be better, but stderr is also an option :-) I'll check that out and post a test version before the next release.
With the log file there is no good way for this to be used in abs that I know of.
I'm assuming when an exit code of 4 is returned this is a critical error and I'm going to ignore the stdout. In that case I could log the error from stderr in abs. For this first implementation I'm going to have abs fallback to ffprobe when a tone dump returns exit code > 0.
Yeah, I would target the stderr output for 0.1.2
...
Should be fixed in the latest code - targeted for 0.1.2
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
hereFfprobe format output:
Now tone dump
Output:
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.