Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding gapless playback to files with deleted tags #75

Open
elandorr opened this issue Aug 5, 2021 · 8 comments
Open

Adding gapless playback to files with deleted tags #75

elandorr opened this issue Aug 5, 2021 · 8 comments

Comments

@elandorr
Copy link

elandorr commented Aug 5, 2021

Hi!

Is it possible to add iTunSMPB tags and/or the ISO standard boxes to already encoded files?

As the iTunSMPB is just a literal tag it's very easy to delete it by accident.

Thank you for making qaac.

Cheers

@nu774
Copy link
Owner

nu774 commented Aug 6, 2021

Not possible, since required information is already lost (you deleted it).

If you have source files, you could just re-encode them.
If you happen to know correct value of iTunSMPB field for a file, then you could manually add it by mp3tag I guess.

@elandorr
Copy link
Author

elandorr commented Aug 9, 2021

Thanks for replying @nu774!

I thought there might be a way to scan the file to add the correct padding. In my usual workflow I ordinarily remove all metadata via fb2k or mp3tag, and only fb2k recently made it preserve the iTunSMPB. For a long-term archive I need to think of these cases because re-encoding isn't possible.

I tried the ISO option, fb2k supports it. Is it possible to write the iTunSMPB based on that? Should be the identical data after all, and it seems the ISO 'metadata' is safe from any conventional workflow/edit.

For anyone else finding this:
I want to know the details of the format I choose, so I researched if it's possible to read/edit the MP4 boxes. I found this: https://gpac.github.io/mp4box.js/test/filereader.html You can find the elst(Edit List), sbgp(Sample to Group), and sgpd(Sample Group Description) by digging through that tree.

Since you're the expert on AAC: What kind of tag format does it use anyway? Some tools show 'Nero', some 'MP4', some even 'ID3' which doesn't seem to make a whole lot of sense. Finding info on AAC is damn hard. For a long-term archive I'd like to know all the things that can go wrong and how to fix them.

MP3 is much easier, the gapless number is identical per encoder, so even if you edit it via fb2k for whatever reason you can easily fix it, and ID3 is not that mystical.

@nu774
Copy link
Owner

nu774 commented Aug 10, 2021

I thought there might be a way to scan the file to add the correct padding.

Generally, no.
If you have the original file, you could tell the duration of it. But that's not enough. qaac offers --num-priming and --no-delay, which makes it practically impossible to tell number of padding samples at the beginning of the file.

For a long-term archive I need to think of these cases because re-encoding isn't possible.

If they are that important but you still stick to a destructive way of tag edditing, why don't you backup iTunSMPB in external text files or something?
You can extract value of iTunSMPB by AtomicParsley for example.

As you say, ISO scheme (edit list) may be better as long as all players you use support it.
Unfortunately, it's not as widely supported as more traditional iTunSMPB as far as I know.

@elandorr
Copy link
Author

elandorr commented Aug 10, 2021

@nu774 I mean I would be careful with AACs then of course, but a mishap shouldn't ruin the file. (like it can happen because we're human, and when you notice later you've ruined the file) Thank you for the background details. MP3s really seem best, as odd as that sounds. Flawless gapless/handling/tagging. But AAC seems superior in listening tests. (am interested in 256-320 high rates, to be safe from 'killer' samples without hesitation)

Also thanks @Zarggg. I suppose 'MP4 boxes' are what is used then. (except for the tool I linked I found very little about those too)

It's a little odd how this proprietary format seems so hacky. With Apple's name on it I'd have expected it to have all this covered perfectly. I have to find a lossy codec to stick with, but the usability/meta/gapless/etc around it is so weird. OPUS also has long threads of issues related to gapless playback, and the developers are seemingly not remotely interested in fixing it. (https://hydrogenaud.io/index.php?topic=117526.0 no response whatsoever and tons more threads like it)

@elandorr
Copy link
Author

No. Apple is also using iTunSMPB there in mp3. FFmpeg does not support applying such meta only reading it in raw form. https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/

Never really used iTunes or came in contact with this proprietary tag before I posted last year. What I meant is that for MP3 the community established standards that work flawlessly with almost everything: foobar2000 of course, or moc or 'deadbeef'. Gapless has no accidental deletion risk like non-ISO AAC here, and it's all somewhat documented.

It is not proprietary and IT WAS THE first format before it became ISO as part of mp4 container.

Interesting, thanks for the background info! I see it's technically an 'open' standard, my apologies. Apple is probably the biggest user with its infinite pockets and own proprietary encoder though and I kinda expected this to mean high quality tools galore. It's odd there is so little open source/community interest in it. Apart from that web based tool I posted there's nothing much to look/edit in detail with the MP4 'wrapper'. I still don't know the whole history, but seeing how there is practically no documentation, I don't need to. It's chaotic. 'Read the source' is unfortunately not a useful option in real life unless this is your exact life goal.
For practical considerations I couldn't care less who did what, although fully open source is a nice bonus. It was fun to learn a bit how this works and do my own testing though.

OPUS is my current choice after all. The gapless issue doesn't seem to happen with foobar2000 (and that's really the single only decent player in my book anyway, unfortunately not open source or for Linux but wine works). I could find some extreme killer samples with OPUS even at high bitrates, but that was a level of extreme that requires hours of highly focused listening, so I decided the benefit of OPUS being superior to MP3 in other situations outweigh the outlier. I do however use a high quality resampler to 48khz first because OPUS' included one is definitely not 'the best'. (Although it's not a very audible difference in real life either.)

I ABX tested many hours and still have to say MP3/lame is exceedingly good. Even Apple's AAC has some edge cases that break it too so quality wise I see no reason to pick it over OPUS. MP3 is remarkably good overall and you don't need to think about any issues with it. OPUS is sort of exotic still and I don't know if any tool besides fb2k handles it properly, gapless worked with VLC at least. Unless you're in the Apple ecosystem I don't see a reason to pick AAC at this point. And unless you're an audio-freak OPUS is too much effort and not that well supported (although it's at least playable on most platforms now).

For anyone who wants to go my way: encoding via current opustools in fb2k, quality of choice (320VBR for me), 'no opus header gain' tag selected in advanced fb2k settings (another example of weird codec specific ways instead of just some common sense tag), instead regular EBU R128 RG tags. These work on FLAC vorbis/MP3 ID3 too and are clearly visible in tag editors and always the same way (just name + value). Whatever is responsible for the original gap issue in the mentioned thread is fine this way. Tags can be cleared and rewritten without consequences too.

I still greatly appreciate the work done here to provide proper and non-iTunes-install-required access to Apple's AAC encoding, and access to proper cli parameters. If anyone ever asks me about AAC I'll send them here. The extraction from the iTunes setup also worked well. Apple's AAC encoder seems slightly better than the properly open source FDK one so it's worth the effort. There have not been a whole lot of tests though lately, this is just the resume of my research.

Cheers and thanks for reading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@nu774 @elandorr and others