Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3 in MP4 container (Read 31557 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 in MP4 container

[span style='font-size:8pt;line-height:100%']split from Problems with lame 3.94beta[/span]

Actually, a standard for gapless MP3 playback does exists, as a part of MP4 file format - I forsee MP4 having much better support in near future than LAME headers. Perhaps LAME needs MP4 writer. But for now, we need consistent way to at least pass LAME gapless decoding info to other software.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #1
The last thing mp3 needs is shoving in a mp4 container, why fragment what is out there for very little (if any) benefit. You might as well put mp3 in a ogg container...

MP3 in MP4 container

Reply #2
Quote
The last thing mp3 needs is shoving in a mp4 container, why fragment what is out there for very little (if any) benefit. You might as well put mp3 in a ogg container...

- MP3 inside MP4 container is a part of MPEG-4 standard, MP3 inside Ogg isn't. Hardware support for MP3-inside-MP4 is to be expected.
- MP4 allows fast sample-accurate seeking of MP3 streams, native gapless playback, use of MP4 tagging with MP3, etc.
If you don't have anything useful to say, or just can't be bothered to do some basic research before spewing BS, please go back to your "unbiased thruth" site instead of trolling HA.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #3
Quote
Perhaps LAME needs MP4 writer.

Would there be much use for that? If my player supports MP4, I could use AAC-in-MP4 instead of MP3. But when I'm more concerned about compatibility (which probably is the most important reason to use MP3) the Lame header seems to be the better place to store gapless information.

MP3 in MP4 container

Reply #4
Quote
Quote
Perhaps LAME needs MP4 writer.

Would there be much use for that? If my player supports MP4, I could use AAC-in-MP4 instead of MP3. But when I'm more concerned about compatibility (which probably is the most important reason to use MP3) the Lame header seems to be the better place to store gapless information.

You can convert MP3 to MP4 and then back to MP3 preserving original LAME header. At least my MP3<=>MP4 converter does so.

The idea of gapless-MP3-inside-MP4 also looks interesting because Winamp is very likely to support it in the future when they finally write proper MP4 support.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #5
Quote
If you don't have anything useful to say, or just can't be bothered to do some basic research before spewing BS,


Not spewing BS, just being a realist - mp3 is on the way out, why bastardise the mp3 standard? (You mention distaste of the mp3 tagging, hey sticking chunks of non mp3 data into the stream has made for very reliable mp3 decoders - not true of mp4 - it is a doddle to crash the iPod).

I am freely allowed to express my opinion, someone who has a program that is used by millions - it will create confusion, more harm than good, not trolling, trying to educate you.
Can you honestly say that the iPod, Creative Range, Rio range of hardware players (talking 99% of the market there) are going to playback mp3 in a mp4 container? dream, dream dream...

BTW I know mp3 is part of the mpeg 4 'standard'. When it comes to audio mp4 should only be AAC, the speech and losslesswhen they are developed.

MP3 in MP4 container

Reply #6
Quote
Can you honestly say that the iPod, Creative Range, Rio range of hardware players (talking 99% of the market there) are going to playback mp3 in a mp4 container? dream, dream dream...

If they already have support for raw MP3 files and MP4/AAC, adding MP4/MP3 should be a relatively simple and non-resource-consuming task.
Quote
BTW I know mp3 is part of the mpeg 4 'standard'. When it comes to audio mp4 should only be AAC, the speech and lossless when they are developed.
What do you base that "opinion" on ?
Quote
You mention distaste of the mp3 tagging, hey sticking chunks of non mp3 data into the stream has made for very reliable mp3 decoders - not true of mp4 - it is a doddle to crash the iPod
Please really educate yourself before posting... MP4 container is extensible, there are legal ways to add user data (using udta atom) and that's exactly what current tagging system does; every compliant MP4 parser will just skip over that chunk if it doesn't know what to do with its contents. You can't expect predictable results after appending non-compliant-garbage to MP4 file, because what you get isn't a valid MP4 file anymore. But indeed, bad data handling in some of available MP4 parsers needs more work.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #7
And I'll restate myself here...
I don't want everyone to convert their MP3s to MP4... I'm just pointing that there's an MPEG-approved standard for gapless playback of MP3 streams that is more reliable than LAME headers (read: its maintainers won't suddenly decide to make non-backwards-compatible changes) and will most likely get better support in near future than LAME headers (I dare to say that having it supported in Winamp looks pretty real). People who care about gapless playback - average "Joe 128kbps" doesn't - should consider using MP4 container as an interesting alternative to LAME tags. Especially that you can convert your files back to MP3 without losing anything.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #8
It sounds interesting. But will all mp3 become gapless when inserted in a mp4 container? Or need they some additionnal datas, like enc_delay and enc_padding, as written (or guessing) with lame tags?
In other words, if fraunhofer doesn't update their encoders anymore in order to add gapless infos, will they be gapless in the future?

MP3 in MP4 container

Reply #9
Quote
It sounds interesting. But will all mp3 become gapless when inserted in a mp4 container? Or need they some additionnal datas, like enc_delay and enc_padding, as written (or guessing) with lame tags?
In other words, if fraunhofer doesn't update their encoders anymore in order to add gapless infos, will they be gapless in the future?

You still need delay/padding infos when converting, and only available "gapless" MP3=>MP4 converter reads them from LAME headers.
As FAQ'd here, you can add LAME headers with gapless playback info to any MP3 file, if you only know encoder delay and exact length.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #10
Thanks for the info.
I was aware about the foobar2000's tool for gapless playback for any mp3 file. But to make it work with other encoders as lame (and proper lame encodings, i.e. without VBRfix ou mp3directcur detour), you need manual setting, which are really fastidious to find (at least at the first time for a given encoder).

Thanks for the clarification


Nota: it's a bit strange to read that mp3 gapless playback is standardized with mp4 container, when aac-mp4 files produced by QuickTime aren't  Nevertheless, nice and innovative feature. Thanks to you for supporting this.

MP3 in MP4 container

Reply #11
Quote
Nota: it's a bit strange to read that mp3 gapless playback is standardized with mp4 container, when aac-mp4 files produced by QuickTime aren't  Nevertheless, nice and innovative feature. Thanks to you for supporting this.

MP4 container has defined measures to remove unwanted samples at the beginning / end of stream - frame offsets (ctts) for skipping first samples, and frame durations (stts) for removing last samples. Those measures aren't codec specific and work in the same way for MP3 and AAC (and HE-AAC). Unfortunately, not all encoders/decoders make use of that. As well as not all MP3 encoders write some kind of gapless playback info to MP3 headers, except this time there is a place for such info defined in the file format.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #12
I tried to play an MP3-in-MP4 sample with Winamp, and to my surprise it DID play  and this happened because i didn't have in_mp4 installed.

MP3 in MP4 container

Reply #13
Quote
I tried to play an MP3-in-MP4 sample with Winamp, and to my surprise it DID play   and this happened because i didn't have in_mp4 installed.

Winamp assumes files with unknown extensions to be MP3, apparently their MP3 decoder can skip MP4 container headers and play raw MP3 data from the file. I highly doubt if the same would work with AAC though (no ADTS headers in MP4 stream). Other than that, you don't get gapless playback or MP4 metadata.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #14
i guess it will also work if nullsoft will add support of the mp4 container in their in_mp3 plugin (afaik it only can play .aac files atm)
I know, that I know nothing (Socrates)

MP3 in MP4 container

Reply #15
Quote
i guess it will also work if nullsoft will add support of the mp4 container in their in_mp3 plugin (afaik it only can play .aac files atm)

Yep, that's exactly why I stated that having proper MP3-inside-MP4 support in Winamp looks real.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #16
Help, no!  ctts and stts are there to document the frames, not to cause trimming.  The timestamp of a frame (access unit) is determined by summing the durations of preceding frames, that's it.  The ctts table is used in video when the presentation timestamp of a frame differs from its decoding timestamp (decoding order), which happens when you have frames with forward dependencies (classic B frames).

Writing a file with a non-0 ctts for the first frame makes no sense.  You're saying "decode this at time 0 but play it at time N", and this is especially problematic if N+the natural duration of the sample (1024 audio samples in AAC, for example) overlaps the start-time of the next or subsequent frames.

There is a document written on mp3-in-mp4 at the MPEG committee, which addresses this and other issues, including the fact that you'd like MP4 (which handles variable length frames) to represent the 'audio' frames as frames, not the mis-aligned 'system' frames (with teh back pointers) that were forced in MP2.

There is also a document on how to handle the extra data added (a) before the true audio data, for codecs with overlapped transforms and (b) the padding needed to round up to a frame boundary.  For both of these, the edit list is ideal.

Finally, if you are overlapping transforms, then random access sounds better if you pre-roll the decoder with a frame before the one you want audio from.  This is indicated with a pre-roll table (first standardized for MP4 for the AVC/H.264 codec).

I hope this helps!  Please don't write ctts tables for audio, if confuses the heck out of software that is interpreting it!

MP3 in MP4 container

Reply #17
Just browsing some ancient threads and I was wondering: is the above poster  making any sense? It seems contrary to what zZzZzZz was saying.

MP3 in MP4 container

Reply #18
Quote
Just browsing some ancient threads and I was wondering: is the above poster  making any sense? It seems contrary to what zZzZzZz was saying.
[{POST_SNAPBACK}][/a]


I talked about this with Menno once.

Quote
Leviathan: [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=16846&view=findpost&p=254841]http://www.hydrogenaudio.org/forums/index....ndpost&p=254841[/url]
Leviathan: So?
m&no: yeah yeah
m&no: he's right
Leviathan: And are you guys considering changing the way gapless info is stored?
m&no: can't really comment on that


So, yeah, I guess Ahead's way of doing gapless needs to be revised.

MP3 in MP4 container

Reply #19
Quote
The last thing mp3 needs is shoving in a mp4 container, why fragment what is out there for very little (if any) benefit. You might as well put mp3 in a ogg container...
[a href="index.php?act=findpost&pid=167254"][{POST_SNAPBACK}][/a]


I actually like the idea.
id3v2 (and v1) are severely lacking. Whoever decided what genres to use in the very limited number of available numbers was STONED when they did it - so you either break the standard, or you comply with the standard and have no holiday genre or inspirational genre because spots were used for things like porn groove and christian gangsta rap.

Getting rid of the ID3 hack and putting the mp3 into a container that can be used with REAL tagging is (imho) a necessity for the format.

I'm speaking from a user perspective.

MP3 in MP4 container

Reply #20
Quote
I actually like the idea.
id3v2 (and v1) are severely lacking. Whoever decided what genres to use in the very limited number of available numbers was STONED when they did it - so you either break the standard, or you comply with the standard and have no holiday genre or inspirational genre because spots were used for things like porn groove and christian gangsta rap.

Getting rid of the ID3 hack and putting the mp3 into a container that can be used with REAL tagging is (imho) a necessity for the format.

I'm speaking from a user perspective.
[a href="index.php?act=findpost&pid=260826"][{POST_SNAPBACK}][/a]


From a users perspective, "hacking" ID3 is totally transparent.

mp3-in-mp4 on the other hand, is what would be confusing..

MP3 in MP4 container

Reply #21
From user's point of view, cuesheet + MP3 playback is either terribly slow or inaccurate.
Tagging shouldn't be a reason for people to convert their MP3 files to another container, unless some relevant software actually supports MP3 in MP4 with tagging but has limited support for MP3 tagging.

As for gapless playback,
At the time I was writing posts above, Menno was quite sure that what we were doing was correct; apparently our interpretations of specs vary, and MP4 parsers some people wrote don't like this idea. Documents we checked before implementing this didn't mention that ctts shouldn't be used with audio tracks. I agree that the whole idea is not exactly clean.
Anyway, you will keep seeing more files using ctts with audio tracks until next major release of Nero encoder is out. Suggested solution (assuming you don't care about introduced gaps) is to ignore ctts on audio tracks.
Microsoft Windows: We can't script here, this is bat country.

MP3 in MP4 container

Reply #22
Next revision of nero encoder will have Nero Digital Gapless data embedded in the MP4 file, fully compatible with the ISO File Format guidelines.

Up to then, only solution is to use current way (ctts with audio track) - but I am sure there will be converters of the data.

 

MP3 in MP4 container

Reply #23
Quote
From a users perspective, "hacking" ID3 is totally transparent.
[{POST_SNAPBACK}][/a]

Alright, so check-out the threads where's a discussion about ID3 Tag!
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=29696&hl=id3+tag]Best Version Of ID3V2[/url]
Another "Is ID3 V2.x evil?" discussion
Tag ID3v2... Why not?
Unfortunately, it's not so black & white as it seems...
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

MP3 in MP4 container

Reply #24
Quote
Unfortunately, it's not so black & white as it seems...


No it's not.
My MP3 CD player expects the spec to be broken - play mp3's encoded AND TAGGED by lame, and it does not display a genre - it displays a number.

Tag them with something else, and I get a genre.
Even if the genre is the same and looks the same in my mp3 playing software, they are not grouped the same in the mp3 cd player because it sees a number for the mp3's tagged by lame.

Yes - the mp3 cd player is out of spec, but that kind of thing is going to happen when you have to break a spec in order to do what the users want done - which is to use genre's that actually make sense in the tags.