MIME type of merge files set as "video/mp4"

[gennaios]

Merging .m4b files with original metadata reported by exiftool:

File Type : M4A
File Type Extension : m4a
MIME Type : audio/mp4

results in:

File Type : MP4
File Type Extension : mp4
MIME Type : video/mp4

I'm having trouble getting them to show up as audio in the default iOS Podcasts app. Seems Podcasts thinks they're video files and displays a video window. Is there anyway to fix already merged files rather than having to re-merge? Maybe some other tool?

[sandreas]

Thanks for reporting. This seems to occur because ffmpeg is told to map all metadata of input files by default - so covers are included as video part and this results in the given mime type.

You could you could use the -vn option of ffmpeg, to remove all video data:

ffmpeg -i test.m4b -vn -acodec copy test_no_vid.m4b

Here is what i tested successfully on my system:

exiftool test.m4b | grep -i mime
# MIME Type : video/mp4
ffmpeg -i test.m4b -vn -acodec copy test_no_vid.m4b
exiftool test_no_vid.m4b | grep -i mime
# MIME Type  : audio/mp4

But I think this will also remove the cover. I'm not sure what you would expect, but if you don't need covers, you could try the --skip-cover option. If this does not help, I would leave this issue open and implement a --no-video flag, that does exactly what i described above...

What do you think?

[sandreas]

Update: ffmpeg seems to ignore -vn parameter when concat is used or a real conversion is done... maybe there is a way that i don't know but for now I added a --fix-mime-type parameter, for me its working now.

I would appreciate your feedback, if the attached m4b-tool version produces working files - don't forget to provide the --fix-mime-type parameter.
m4b-tool.zip

[gennaios]

Thank you for looking into it. I remade the merged files since before I didn't know about the --no-conversion option. Used that and --fix-mime-type and the metadata looks ok. Will test soon with the iOS Podcasts app but I assume it will be ok.

I think for usability, --no-conversion should be default. Same with preserving the original mimetype if possible, if somehow m4b-tool could detect the original and use that. I think that'd be much better and any parameters should be for changing default behavior. "merge" I think should be just that, with original encoding, metadata, etc.

[gennaios]

iOS Podcasts still shows a video window, though it may be due to something else. I'll verify podcast settings though I thought that was ok.

Unrelated, using option --no-conversion, tracks seem to not be merged and there's no chapter info.

[gennaios]

Figured out that in the podcast xml file, type needs to be "audio/x-m4a". "audio/x-m4b" is what shows a video window; perhaps the app doesn't read the file metadata. So perhaps the mime type is of less importance for podcast publication though I think it is still preferable to retain the original metadata if possible. I haven't tested the combination of "audio/x-m4a" with files without the "--fix-mime-type" option; if you'd like, I could.

[sandreas]

I think should be just that, with original encoding, metadata, etc. [...] I think it is still preferable to retain the original metadata if possible. I haven't tested the combination of "audio/x-m4a" with files without the "--fix-mime-type" option; if you'd like, I could.

If --no-conversion or --fix-mime-type are used, metadata is handled exactly the same way as without the parameters, so metadata should be transferred correctly - if not i would need a sample command line and some files to reproduce it.

I think for usability, --no-conversion should be default. Same with preserving the original mimetype if possible, if somehow m4b-tool could detect the original and use that. I think that'd be much better and any parameters should be for changing default behavior.

I am absolutely your opinion. Using sane defaults is something that is very important to me and i already tested codec detection and automatically skipping the conversion step. I understand that the extra encoding step is time consuming and produces little lower audio quality, which really does not make sense.

That said, ffmpeg is a bit tricky on this one... m4b-tool uses ffmpegs concat multiplexer to merge files and unfortunately this often produces corrupt files, because multiplexing also skips ffmpegs auto encoding feature. At least in my tests the encoding skip wasn't reliable. Even if the codec seemed to be detected correctly, some of the resulting merged files were corrupt unless they were re-encoded.

So the most reliable way to merge files in a simple command line interface (which is one of m4b-tool's goals) is to do a conversion before the merge by default. I hope you can follow my argumentation that default parameters should avoid the possibility of producing corrupt files, even if this has some disadvantages. But as i understand your problem with this decision, the two command line parameters --no-conversion and --fix-mime-type will be provided in future versions until i found a better solution.

Figured out that in the podcast xml file, type needs to be "audio/x-m4a". "audio/x-m4b" is what shows a video window; perhaps the app doesn't read the file metadata. So perhaps the mime type is of less importance for podcast publication

So as m4b-tool does not seem to cause the problem in your case, i would like to close this bug as invalid if you didn't mind - but thank you for your feedback and for testing the new flag...

Is this ok?

[gennaios]

If --no-conversion or --fix-mime-type are used, metadata is handled exactly the same way as without the parameters, so metadata should be transferred correctly - if not i would need a sample command line and some files to reproduce it.

I'll send you some files. Without --fix-mime-type .m4bs of mime type "audio/mp4" turn into "video/mp4".

So as m4b-tool does not seem to cause the problem in your case, i would like to close this bug as invalid if you didn't mind - but thank you for your feedback and for testing the new flag...

Thank you for the help. Yes you can close this.

[gennaios]

Do you have an email I can send files to? I mostly have commercial audiobooks I'm merging and prefer to share another way. I'm finding that with --no-conversion and I believe --skip-cover, plus first removing covers with AtomicParsley, mime type is still set to video unless I use --fix-mime-type. I haven't tested all combos of parameters but that seems to be the case.

[sandreas]

Thank you for offering the original files, but i think we should not share commercial audiobooks for legal reasons.

I think you have a specific workflow. Perhaps it would be useful, if you describe the whole process in, what you would like to do, how your directories are structured and which commands you are executing, so that i can try to reproduce the problem and fix the problems that you are facing instead of adding more and more flags that are very specific and not what you need. I think there must be a more generic way to handle this.

What do you think?

[gennaios]

sounds good, thank you.

It does seem that --fix-mime-type is always needed for me otherwise I get a MIME type of video/mp4. Steps are:

• source files are usually .m4as imported w/iTunes, either CDs or converted lossless, and renamed to .m4b.
• when needed, I merge files to be one "chapter" or "book" per file, such as if a a chapter in a work is divided among multiple files, so a work chapter or book appears as multiple chapters in one file.
• copy files to a temp folder on desktop
• run a command to store merged files in another temp folder.

With source files in ~/temp2, command is usually:

m4b-tool merge * --skip-cover --no-conversion --output-file="/Users/----/Desktop/temp/01.m4b"

btw, I've noticed sometimes chapter marks are incorrect. Have you seen that? Maybe source files were incorrectly split (will have to verify) but I think they are ok. When I have a chance to look again, I can make a new issue if that is the case.

[sandreas]

It does seem that --fix-mime-type is always needed for me otherwise

Yes, and there unfortunately is no way around this. The flag is needed because ffmpeg does not produce audio/mp4, when parameters are present, that m4b-tool requires for the merge, even if i add the -vn ffmpeg-param (for no video), mimetype is still video/mp4.

Since an extra transcoding-step is required to fix it and the video/mp4 mimetype did not cause problems in any of my use cases, the flag --fix-mime-type will be required to switch mimetype to audio/mp4 until ffmpeg changes this behaviour. At the moment i can't do anything about it in m4b-tool except the --fix-mime-type workaround, sorry.

With source files in ~/temp2, command is usually: [...]

Looks reasonable to me. I would recommend a little change for the next m4b-tool version, where --fix-mime-type should work correctly:
m4b-tool merge /Users/----/Desktop/temp/ --skip-cover --no-conversion --fix-mime-type --output-file="/Users/----/Desktop/temp_output/01.m4b"

• --fix-mime-type performs an inplace recode to switch to audio/mp4 mimetype keeping the metadata
• Using /Users/----/Desktop/temp/ instead of * results in a faster and better handling of files, reason is the shell expansion of * - m4b-tool works with directories and searches recursively out of the box

This issue is degenerating a little. To summarize, here are the two things that did not work for you, at least in some cases:

• if you use the --fix-mime-type parameter, metadata of the original files is not retained => this should be fixed in the next version, but I'll double check with your commands and some more of my testing m4b files
• chapter marks are incorrect => I never heard of this happening and all my files worked like a charm, but if this happens again, please open a new issue - it would help a lot, if you use use --debug parameter, and provide ...chapter.txt and m4b-tool_debug.log - please make sure you removed sensitive information

For now, i handle this issue as closed, new issues with more specific description help me to save more time for development.

Thank you for your effort.

[gennaios]

Thanks for the clarification. Agree about the issue degrading. It works for me and I don’t mind specifically using some parameters. Just sought some clarification.

As for —no-conversion, perhaps some of my steps can be done by default so that —no-conversion can someday be default and work without error. Minor thing for the future if it’s worth it. Will create new issues if I find something else.