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: .M4A -> .ADTS (Read 4286 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

.M4A -> .ADTS

I need to write a function that takes a file pointer to a .m4a file and converts it to a .adts file (or the direct data) for playback with our AAC decoder.  We don't really want a monster library of other stuff, just this simple function.  I thought I could just write out the mp4 'mdat' atom contents as implied by what I read from AtomicParsley but the AAC decoder doesn't like that. It spits out about a dozen frames of zeros and then returns an error. Could someone please point me to the specification for the adts file, or explain to me what I am doing wrong, or better yet offer a function that already does the conversion?  Is there some intricate decoding that needs done here or is it as simple as an offset into the mp4 file?

.M4A -> .ADTS

Reply #1 –
If your MP4 file has only 1 data track, namely the AAC track, the data in the MDAT atom will contain RAW AAC data, so without ADTS header. A decoder could decode this as long as it knows the right samplerate. To add ADTS headers you will really need to know how big the frames are, by parsing the MP4 file and add ADTS headers manually in front of each.
To make a long story short: what you want to do is already possible with mp4creator (extract track).

.M4A -> .ADTS

Reply #2 –
Thanks alot!  I looked deeper into it and turns out there were 8 zeros (0x00) between the 'mdat' tag and the first actual 'frame' of encoded music data.  After skipping over these 8 bytes it now decodes fine and sounds good assuming I have the sample rate set right... 

Just two questions more...

1. Currently my parser just skips any zero (0x00) bytes after the 'mdat' before sending the data to the decoder.  This works for the iTunes files I got that seem to start with either 0x20 or 0x21 but I am not confident this simple method will work all the time.  Is there a better simple method to determine where the actual decoder data begins after the 'mdat' without being overly complicated? It really just needs to work for apple song from current and future versions of iTunes.  I just don't want to make any assumptions on the data that will be broken on someone else's computer or in a week.

2. Eventually I will also need to actually read the sample rate from the file to set that appropriately.  Is there an easy atom like 'mdat' to look for in the file that will tell me this rate?  Most of the files are 44100 hz so currently I just use that but it would be nice if it could read this from the MP4 file.


Appreciate your help on this!

.M4A -> .ADTS

Reply #3 –
If you need a foolproof solution, you're really going to have to parse the file.  Depending on how the ISO Base Media was created, your assumptions could be way off.    If this is for your own use for a set of tracks created with a known encoder, then your hacky method might suffice.

This would be pretty easy to do with libmp4v2 from MPEG4IP.  I've written code to do this for special purposes before.  I can probably write up some sample code if you're interested.

.M4A -> .ADTS

Reply #4 –
Thanks alot!  It is now working great! The next project is to unwrap whatever format WMA files come in to send that data to our WMA decoder... any pointers here?  Once again the ideal solution would be some simple function that says jump to this index in the file and start decoding...