.aac to .m4a.. possible?

[romi7519]

hi all!

i need to change some aac files to m4a, is it poss without re-encoding?
i did try changing the extension but the media player rejected the files.

thanks in advance!

[jagabo]

Yamb can mux it an MP4 file (without any video). Maybe that will work.

[romi7519]

i need m4a.

[Midzuki]

"M4A" is a "non-existent" file extension which was invented by the
marketeers from Apple. It means AAC or ALAC stream wrapped
in an MP4 container.


\\\\\

[t0nee1]

If you have the original file(s), encode/convert to AAC/m4a extension..Or if not then just re-encode and this time use the .m4a extension..It'll only take a few sec. per track...

[poisondeathray]

You can use ffmpeg,

In this example , "1.aac" is copied and muxed into a .m4a container, "2.m4a" - all it does is re-wrap the .aac audio in the apple container

ffmpeg -i 1.aac -vn -acodec copy 2.m4a

I'm curious why you need it? All players that can play .m4a should be able to play .aac

[mikk]

thanks, this is useful for a particular alpine head unit after ripping the audio from a youtube video.

[ARTO65]

Also, if you want to make a ringtone for your iPhone, iTunes will only accept .m4a, not aac. And you have to rename the extension .m4r.

[aero8800]

find . -name "*.aac" -exec bash -c 'avconv -i "$1" -acodec copy "${1%.*}.m4a"' _ {} ';'

Bash won't stop on errors so you need to count the output files and compare:
find . -name "*.aac" | wc -l
find . -name "*.m4a" | wc -l

Then remove all aac:
shopt -s globstar; rm ./**/*.aac

If you're going the other way round (m4a > aac) you probably need to check that they're aac and not alac with ffprobe:
find . -name "*.m4a" -execdir bash -c 'ffprobe "$1" 2>&1 | grep alac' _ {} ';'

[Mephesto]

Use MP4Box.

"C:\\Program Files\Yamb\MP4Box.exe" -add "C:\moon.aac" -new "C:\moon.mp4"

[omelette]

Use MP4Box.

"C:\\Program Files\Yamb\MP4Box.exe" -add "C:\moon.aac" -new "C:\moon.mp4"

Hi. First my situation. I have lots of Streamripper-ripped aac files that many media players recognise as unknown files, or audio files of zero length, the reason being that Streamripper doesn't include header information with the 'raw' aac data. What I have been doing till now is using ffmpeg to recode them, ending up with files that are recognised and have title/album info included.

The problem with ffmpeg (and re-coding in general I suspect) is that there is a loss in audio quality when I do this. But much more annoying, despite setting the bit-rate, ffmpeg refuses to encode at anything lower than 59kbits/sec, so I end up with files 3-4 times larger than the originals. Given that the originals are of low quality to begin with, I find these trade-offs unacceptable.

Enter MP4Box. I saw your post, tried it and was elated to find that the file sizes and audio quality stay the same. Actually the files end up a little smaller - it seems that using the above comand, MP4Box is dumping some header information, namely the track title/album information - which to me is a bummer! What do I have to include in the above command to preserve this information???

Edit: Just discovered another problem. MP4Box takes a 22050Hz stereo file and spits out a single-channel mono file - must be a bug. Better quality stereo 48Kbits/sec files (also created by Streamripper) result in the expected 2-channel files. I guess MP4Box won't be my saviour after all.

[hello_hello]

MP4Box just remuxes. It can't change the audio as such. How are you verifying that's what it's doing?

I use Video To Video Converter for muxing AAC audio now and then (select direct stream copy from the list of conversion presets if you don't want to re-encode, then pick the desired output container on the right). For some reason though, the current version has an issue muxing raw AAC into an M4A container and it spits out an error. The current version is 2.9.something. I'm fairly sure the 2.8.* versions remux raw AAC fine. The advantage of Video To Video converter is you can do batch muxing. I've reported the AAC remuxing bug, which will hopefully be fixed in the next version. You can probably find links to old version on the VideoHelp page for Video To Video converter.

You can mux raw AAC as MKA files with MKVMergeGUI.
If you're not happy with MKA, Video To Video Converter will happily remux them as M4A files, it just doesn't like raw AAC streams at the moment.

The above are some alternative ideas. I have no idea regarding retaining the header information. I didn't think raw AAC files could store track and title information, but maybe I'm wrong. For managing MP3 and M4A tags, as well as other file types, I use Mp3Tag. It might take a little getting used to, but it's quite a good program.

[omelette]

MP4Box just remuxes. It can't change the audio as such. How are you verifying that's what it's doing?

Hi. Two ways - opening both files (the original and the one produced by MP4Box) with Audacity. The original shows a stereo 2-channel audio file, whereas the MP4Box file is shown as containing just a mono 44100Hz single channel. Also using MP4Box's '-info' option, 2-channels in, but -info shows the file produced by MP4Box as containing only one channel. Like I said, using a higher bitrate (48Kbits/sec file) I get the expected 2-ch in, 2-ch out. BUT - Movie Player and VLC list the supposedly-mono files as being stereo, so I'm confused as to what's happening. Maybe MP4Box is saving both channels but filling in the 'container' details incorrectly - Audacity and its own -info certainly seem to think so. Again, no such problems where higher bitrates are involved.

I use Video To Video Converter for muxing AAC audio now and then (select direct stream copy from the list of conversion presets if you don't want to re-encode, then pick the desired output container on the right). For some reason though, the current version has an issue muxing raw AAC into an M4A container and it spits out an error. The current version is 2.9.something. I'm fairly sure the 2.8.* versions remux raw AAC fine. The advantage of Video To Video converter is you can do batch muxing. I've reported the AAC remuxing bug, which will hopefully be fixed in the next version. You can probably find links to old version on the VideoHelp page for Video To Video converter.

You can mux raw AAC as MKA files with MKVMergeGUI.
If you're not happy with MKA, Video To Video Converter will happily remux them as M4A files, it just doesn't like raw AAC streams at the moment.

Thanks, I'll check VTVC out.

The above are some alternative ideas. I have no idea regarding retaining the header information. I didn't think raw AAC files could store track and title information, but maybe I'm wrong. For managing MP3 and M4A tags, as well as other file types, I use Mp3Tag. It might take a little getting used to, but it's quite a good program.

I suspect you may be right about aac files containing no header information, But, when I open a aac file produced by Streamripper with Movie Player, the Title, Artist and Duration fields are populated, whereas with VLC, just the title is populated, but with both Title & Album information - it seems that programs just make a 'best-guess' at filling in the various fields from the file name when no header information is available. Both get the Duration right though, whereas the Decibel audio player lists the Streamripper files as having zero duration. So it's a mixed bag!

Doesn't help me though - I have thousands of Streamripper files whose Title/Artist details I really want to preserve. The only 'solution' I have come across involves using Foobar2000, but apparently each file needs to be processed individually, which for the numbers that I'm dealing with, makes it impractical. On the face of it, MP4Box does most of what I need doing, namely re-wrapping without re-encoding. It's just let down by this 2-ch -> 1-ch thing. Worst case scenario, I will just have to write a Bash script and use MP4Box's -meta option to populate the Title & Artist fields.

Edit: On second thoughts, there must be some header information included in Streamripper aac files - when I rename one of these to some thing else, Movie Player still has the Title, Artist & Duration fields filled out correctly, so it is getting the information from somewhere.

[omelette]

The following realisations may be of interest to someone. First, there's no need for MP4Box to remux, ffmpeg will also do the job. Below is a little Bash script that will convert all *.aac files in a folder to their mp4 equivalents. While line #1 works perfectly, the new mp4 containers do not have any Title or Artist information included. When I discovered the line #2 info, I throught I had cracked the problem. This variant will include the Title & Artist information from the Streamripper files, but only about 80% end up as usable files - the remaining 20% will not playback! Worse, the only way to find out which are duds is to run them - sloppy! So there seems to be no 'clean' way of doing this, which is a pity.

Edit: Oops, line #1 DOESN'T work - it produces files but with no audio streams!!!

Edit2: Damn, I was right first time around - line #1 works fine with the current ffmpeg. But not with an older ffmpeg version.

#!/bin/bash
for i in *.aac
do
#ffmpeg -i "$i" -c copy -f mp4 "${i%aac}mp4" #1
ffmpeg -i "$i" -c copy -bsf:a aac_adtstoasc -f mp4 "${i%aac}mp4" #2
done

[hello_hello]

Any chance of a couple of samples? I wouldn't mind have a play with one of the 22050Hz stereo files to see what happens (I suspect it's really a mono file being decoded differently before/after remuxing), and maybe one containing the artist/title information. Just out of curiosity really, but I may be able to help a little in the process.

If you load a raw AAC stream into foobar2000 you'll see it doesn't display any duration. In fact you can't even navigate to a different point in the file while it's playing. Put the AAC in an M4A or MKA container and the duration is displayed and you can navigate normally. I think for raw AAC, some programs look at the average bitrate and take a guess at the duration. Or they scan the whole audio. For CBR audio it'd be easy to correctly work out the duration from the bitrate. For VBR AAC it might be a bit harder.

You can batch convert with foobar2000. Just load as many AAC files as you desire into a playlist, highlight them all, right click and select convert, but it'd be better to simply remux them instead. foobar2000 can't just remux, as far as I know.

[poisondeathray]

Are you using the correct switches in mp4box?

22.05Khz AAC audio will likely be low bitrate HE-AAC v1 or v2 (aka SBR or PS) . You might need to use -sbr for SBR, -ps for PS

[omelette]

Any chance of a couple of samples? I wouldn't mind have a play with one of the 22050Hz stereo files to see what happens (I suspect it's really a mono file being decoded differently before/after remuxing), and maybe one containing the artist/title information. Just out of curiosity really, but I may be able to help a little in the process.

Sure. Here are 4 - 2 at the lowest bitrate & another 2 at a higher bitrate, plus their mp4 conversions using ffmpeg.

I was royally confused for a time (see above post edits) because I'm switching between two 2 different OS's - Ubuntu 10.04 with 'old-everything' installed, and Mint 17.1 which I will be forced to switch to eventually. Much prefer Ubuntu 10.04 though as Mint-Mate is incredibly & unbelievably buggy - but time moves on...

If you load a raw AAC stream into foobar2000 you'll see it doesn't display any duration. In fact you can't even navigate to a different point in the file while it's playing. Put the AAC in an M4A or MKA container and the duration is displayed and you can navigate normally. I think for raw AAC, some programs look at the average bitrate and take a guess at the duration. Or they scan the whole audio. For CBR audio it'd be easy to correctly work out the duration from the bitrate. For VBR AAC it might be a bit harder.

Yeah, it confuses things more that some programs show zero-duration (Decibel with me), whereas others show the correct duration. This confusion is compounded when it somes to showing Title/Artist information - if it isn't contained in the Streamripper-produced aac-header, how does Movie Player & VLC manage to fill in the info?

You can batch convert with foobar2000. Just load as many AAC files as you desire into a playlist, highlight them all, right click and select convert, but it'd be better to simply remux them instead. foobar2000 can't just remux, as far as I know.

Haven't tried Foobar2000 in ages. I'll have to have a play with it.

Edit: Forgot to mention, when I process the 'Captain Jack' track with line #2 of the Bash script, it produces an invalid audio file, whereas the other 3 are playable. Note that all of them retain their Title/Artist info when processed with line #2, whereas they all lose it when processed with line #1.

[omelette]

Are you using the correct switches in mp4box?

22.05Khz AAC audio will likely be low bitrate HE-AAC v1 or v2 (aka SBR or PS) . You might need to use -sbr for SBR, -ps for PS

I wasn't using any switches, just "MP4Box -add "foo.acc" -new "foo.mp4". But like I said, when I run this for higher bitrate stereo-files, MP4Box produces a stereo-mp4 file - as seen by media players as well as its own -info option. Whereas 'MP4Box -info 'foo.mp4' will show the file that it produced from the low-bitrate stereo file as having only one audio stream. Audacity displays it as a single channel stream as well, whereas media players show it as still being a stereo file - hence the confusion on my part.

[hello_hello]

Of your samples:

Captain Jack - Viva La Vida (Radio Mix): AAC SBR+PS
Dualxess - Died In Your Arms 2k12 (City Angels Extended Mix): AAC SBR
Fresh Fox - Big Boys Dont Cry: AAC SBR
Wienna - Little angel: AAC SBR+PS

At least that's what foobar200 says. They're all stereo 44.1k
The way I understand it, AAC SBR = HE-AAC and AAC SBR+PS = HE-AAC version 2. Someone may be able to correct me if that's wrong.

Your MP4 samples are a mess. The two AAC SBR+PS MP4s are being imported by Audacity as 22050 mono and playing at half speed, but that's the opposite of what you said was happening, I think. The raw AAC files import okay. All import as stereo 44.1k.
foobar2000 wouldn't play the MP4 versions and Video To Video Converter didn't like them. They played in MPC-HC with ffdshow decoding, which displayed each as 44.1k stereo each time via it's tool tip. Maybe the MPC-HC splitter is a lot more tolerant when it comes to bad muxing. I don't fully understand how it all works. MediaInfo displays your MP4s as being stereo.

I'm not seeing any title or artist information in the AAC files, unless I don't know how to find it. I suspect the muxing program is using the file name to create the tags when muxing as MP4.

I was able to successfully create MP4s that would import into Audacity and play in foobar2000 using YAMB, by adding the audio, clicking on properties and selecting "backward non-compatible" for the HE-AAC signalling option. It seems mandatory for the AAC SBR+PS files but doesn't seem to hurt when muxing the AAC SBR files. Sample command line:
"c:\program files\yamb\mp4box.exe" -add "E:\Wienna - Little angel.aac: sbrx" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" -new "E:\Wienna - Little angel.mp4"
I tried updating the version of MP4 box that comes with YAMB but I wasn't successful in getting YAMB to play with any newer versions. I ran out of time to learn more about the MP4Box command line, but the bit highlighted in blue seems to be what makes the difference. There shouldn't be a space between aac: and sbrx but I had to add one to stop the forum software form turning part of it into a smiley.

For some reason, after muxing foobar2000 sees all the MP4s as AAC SBR (not AAC SBR+PS where applicable). I'm not sure why, but they play okay and import into Audacity fine.

By far the easiest method for muxing these (aside from maybe batch muxing via a command line) is to use MKVMergeGUI. Just open an AAC file, select "start muxing" and you'll have an MKA in no time. It automatically checks the SBR/HE-AAC option. For some reason though, foobar2000 sees each MKA as AAC SBR as it does for the MP4. I don't know why. If I deselect the SBR/HE-AAC option when muxing it does see the AAC SBR+PS audio as AAC SBR+PS, not just AAC SBR. I suspect deselecting the SBR/HE-AAC option when muxing with MKVMergeGUI would be a bad idea. Maybe what foobar2000 displays is just a foobar2000 oddity. I don't know. I might have to investigate more at some stage.

Once the audio is muxed as MP4 or MKA, tagging it using the file name shouldn't be hard. I'd do it with Mp3Tag. You can open a bunch of files, right click, select "Convert/File Name to Tag" and you can configure it to use all the file names to tag them correctly. If they're all named the same way (artist - title) it should be pretty easy. From there mp3Tag, or another program, might be able to download more ifo to use when tagging. I haven't played with that much yet.

I didn't have much luck muxing the AAC files with Video To Video Converter as it seems a bit broken when it coms o AAC and M4A at the moment.

I ran out of time to experiment with ffmpeg muxing. Or trying MP4Box via a command line. Maybe tomorrow. Hopefully some of that will point you in the right direction though.....

Edit: It seems selecting either "backward compatible" or "backward non-compatible" for YAMB produces a working MP4. For the former you get this instead of the command line mentioned earlier:
"c:\program files\yamb\mp4box.exe" -add "E:\Wienna - Little angel.aac: sbr" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" -new "E:\Wienna - Little angel.mp4"

[omelette]

Of your samples:

Captain Jack - Viva La Vida (Radio Mix): AAC SBR+PS
Dualxess - Died In Your Arms 2k12 (City Angels Extended Mix): AAC SBR
Fresh Fox - Big Boys Dont Cry: AAC SBR
Wienna - Little angel: AAC SBR+PS

At least that's what foobar200 says. They're all stereo 44.1k
The way I understand it, AAC SBR = HE-AAC and AAC SBR+PS = HE-AAC version 2. Someone may be able to correct me if that's wrong.

Thanks for taking a look at them. Yep, all stereo like I said.

Your MP4 samples are a mess. The two AAC SBR+PS MP4s are being imported by Audacity as 22050 mono and playing at half speed, but that's the opposite of what you said was happening, I think. The raw AAC files import okay. All import as stereo 44.1k.
foobar2000 wouldn't play the MP4 versions and Video To Video Converter didn't like them. They played in MPC-HC with ffdshow decoding, which displayed each as 44.1k stereo each time via it's tool tip. Maybe the MPC-HC splitter is a lot more tolerant when it comes to bad muxing. I don't fully understand how it all works. MediaInfo displays your MP4s as being stereo.

Well, that 'mess' is courtesy of both ffmpeg & MP4Box! I think you misread what I said - I said that Audacity (and MP4Box's -info option) displayed the mp4 files it produced as mono files - precisely what you found. The half-speed thing is where different versions of Audacity produce different results - in my Ubuntu 10.04 setup, Audacity version 1.3.12beta is installed and doesn't produce the half-speed problem. What it does is crash unceremoniously whenever it tries and fails to open a 'non-standard' audio file. On Mint 17.1, the up-to-date Audacity has the slow-down, but I hadn't checked it on that.

I'm not seeing any title or artist information in the AAC files, unless I don't know how to find it. I suspect the muxing program is using the file name to create the tags when muxing as MP4.

Attached is what I see when I open all of the Streamripper aac files, as well as the mp4 files that ffmpeg produced with the line #2 of the Bash script, with Movie Player. Running line #1 (or the MP4Box variant) the mp4 file produced would have all of the 'General' fields set to 'unknown'. With Streamripper aac files, both VLC and Decibel media players have all of these fields set to 'unknown'. Like I mentioned already in one of my edits, when you change the name of a Streamripper aac file (to "test.aac" for example) and then convert it to a mp4 file using line #2 of the Bash script, both Movie Player & VLC display the correct Title/Artist of the track produced - so it can't be just using the information contained in the file-name.

I was able to successfully create MP4s that would import into Audacity and play in foobar2000 using YAMB, by adding the audio, clicking on properties and selecting "backward non-compatible" for the HE-AAC signalling option. It seems mandatory for the AAC SBR+PS files but doesn't seem to hurt when muxing the AAC SBR files. Sample command line:
"c:\program files\yamb\mp4box.exe" -add "E:\Wienna - Little angel.aac: sbrx" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" -new "E:\Wienna - Little angel.mp4"
I tried updating the version of MP4 box that comes with YAMB but I wasn't successful in getting YAMB to play with any newer versions. I ran out of time to learn more about the MP4Box command line, but the bit highlighted in blue seems to be what makes the difference. There shouldn't be a space between aac: and sbrx but I had to add one to stop the forum software form turning part of it into a smiley.

For some reason, after muxing foobar2000 sees all the MP4s as AAC SBR (not AAC SBR+PS where applicable). I'm not sure why, but they play okay and import into Audacity fine.

By far the easiest method for muxing these (aside from maybe batch muxing via a command line) is to use MKVMergeGUI. Just open an AAC file, select "start muxing" and you'll have an MKA in no time. It automatically checks the SBR/HE-AAC option. For some reason though, foobar2000 sees each MKA as AAC SBR as it does for the MP4. I don't know why. If I deselect the SBR/HE-AAC option when muxing it does see the AAC SBR+PS audio as AAC SBR+PS, not just AAC SBR. I suspect deselecting the SBR/HE-AAC option when muxing with MKVMergeGUI would be a bad idea. Maybe what foobar2000 displays is just a foobar2000 oddity. I don't know. I might have to investigate more at some stage.

Once the audio is muxed as MP4 or MKA, tagging it using the file name shouldn't be hard. I'd do it with Mp3Tag. You can open a bunch of files, right click, select "Convert/File Name to Tag" and you can configure it to use all the file names to tag them correctly. If they're all named the same way (artist - title) it should be pretty easy. From there mp3Tag, or another program, might be able to download more ifo to use when tagging. I haven't played with that much yet.

I didn't have much luck muxing the AAC files with Video To Video Converter as it seems a bit broken when it coms o AAC and M4A at the moment.

I ran out of time to experiment with ffmpeg muxing. Or trying MP4Box via a command line. Maybe tomorrow. Hopefully some of that will point you in the right direction though.....

Edit: It seems selecting either "backward compatible" or "backward non-compatible" for YAMB produces a working MP4. For the former you get this instead of the command line mentioned earlier:
"c:\program files\yamb\mp4box.exe" -add "E:\Wienna - Little angel.aac: sbr" -itags tool="Yamb 2.1.0.0 [http://yamb.unite-video.com]" -new "E:\Wienna - Little angel.mp4"

Most of the above I'm unfamiliar with so will have to check out. I had already found YAMB and got it working but quickly lost interest when I discovered that MP4Box blitzed the Title/Artist information during conversion. Call me pedantic but I would have thought that it would have occurred to the developers of MP4Box that users interested in converting raw aac files to the mp4 format would also want the Title/Artist information preserved. After all, this occurred to the ffpmeg developers, as line #2 of the Bash script does this - although about 20% are unplayable! Of course this comes back to the question of whether or not there is any meta-data stored in raw aac files to begin with - I always thought not, but the conversion results just mentioned seems to suggest otherwise!

Anyway, I appreciate you looking into this.

[poisondeathray]

Of course this comes back to the question of whether or not there is any meta-data stored in raw aac files to begin with - I always thought not, but the conversion results just mentioned seems to suggest otherwise!

Yes metadata is in your original files. You can use mediainfo to view it. If the conversion had only used the filename for the "metadata", changing the filename would change the metadata, but this isn't the case

One way you can tranfer the metadata is with ffmpeg, using 2 commands, one to get the metadata written to text file, and -map metadata 1 to write it later; but if ffmpeg muxes have problems (ffmpeg's mp4 muxer doesn't have switches like mp4box for -sbr -ps) you might need another tool . ffmpeg doesn't allow for in place editing (editing without remuxing the container)

e.g

ffmpeg -i "Wienna - Little angel.aac" -f ffmetadata Wienna_metadata.txt

This is what the data looks like in plain text

;FFMETADATA1
artist=Wienna
title=Little angel
encoded_by=Ripped with Streamripper
track=108
encoder=Lavf56.12.100

[ndjamena]

I haven't read the entire thread and I don't know if it's relevant but if you encode a stereo stream at a low enough bitrate AAC encoders are well within their rights to switch to a mono channel midstream when the bitrate is no longer sufficient to maintain two separate channels. That may be what's throwing MP4Box off.

[hello_hello]

It looks like poisondeathray is correct. There is title and artist info in the AAC files. MP3Tag doesn't display it, and fooba2000 doesn't display it, but it appears MediaInfo does.

If ffmpeg's muxer doesn't have switches for -sbr -ps as MP4Box does, you're probably not going to be able to use it. I don't know why, but there doesn't seem to be many MP4Box GUIs that support muxing audio only. My MP4BoxGUI doesn't, MeGUI's MP4 muxer doesn't. YAMB does, but I don't know of any others.

If MKA was suitable for the output container, it'd be so much easier with MKVMergeGUI. It doesn't do any tagging, but if all the files are neames artist and title, it shouldn't be hard to automatically tag them with something like MP3Tag.

[omelette]

Of course this comes back to the question of whether or not there is any meta-data stored in raw aac files to begin with - I always thought not, but the conversion results just mentioned seems to suggest otherwise!

Yes metadata is in your original files. You can use mediainfo to view it. If the conversion had only used the filename for the "metadata", changing the filename would change the metadata, but this isn't the case

One way you can tranfer the metadata is with ffmpeg, using 2 commands, one to get the metadata written to text file, and -map metadata 1 to write it later; but if ffmpeg muxes have problems (ffmpeg's mp4 muxer doesn't have switches like mp4box for -sbr -ps) you might need another tool . ffmpeg doesn't allow for in place editing (editing without remuxing the container)

e.g

ffmpeg -i "Wienna - Little angel.aac" -f ffmetadata Wienna_metadata.txt

This is what the data looks like in plain text

;FFMETADATA1
artist=Wienna
title=Little angel
encoded_by=Ripped with Streamripper
track=108
encoder=Lavf56.12.100

YES! Finally some clarity on this raw aac issue - this uncertainty has been bugging me for years! MediaInfo is a great little app as well, particularly since the developers have builds available for even my old long-EOL'ed Ubuntu 10.04. It also reveals why Audacity is having problems with some of the mp4 containers that the line #2 for ffmpeg produces (the Captain Jack track for instance) - or at least it shows that there is something decidely odd about it, having 2 channels, but then not populating them the same way as it does when using it to look at the raw aac of the same file.

I'll have to recheck (having tried a gazillion variations already) but I think all of the files are playable when the line #1 form for ffmpeg (from the above Bash script) is used, as well as its MP4Box counterpart. So on the face of it, it would appear it's just a case of making it a 2 or 3-part operation - or at least I thought so until I read your line " ffmpeg doesn't allow for in place editing (editing without remuxing the container)" - I guess I'll just have to have a play with ffmpeg and see!

Thanks for the valuable info.

[omelette]

It looks like poisondeathray is correct. There is title and artist info in the AAC files. MP3Tag doesn't display it, and fooba2000 doesn't display it, but it appears MediaInfo does.

If ffmpeg's muxer doesn't have switches for -sbr -ps as MP4Box does, you're probably not going to be able to use it. I don't know why, but there doesn't seem to be many MP4Box GUIs that support muxing audio only. My MP4BoxGUI doesn't, MeGUI's MP4 muxer doesn't. YAMB does, but I don't know of any others.

If MKA was suitable for the output container, it'd be so much easier with MKVMergeGUI. It doesn't do any tagging, but if all the files are neames artist and title, it shouldn't be hard to automatically tag them with something like MP3Tag.

Yes, mediainfo helps enormously in clarifying things!

It appear the mono problem when remuxing low bitrate files has to do with this. There are also a couple of relatively-recent submitted ffmpeg bug reports that seem to have gotten short shrift from the ffmpeg developers regarding '-bsf:a aac_adtstoasc' usage - here for instance - resulting in unplayable tracks, just like is happening here, but only with some of the files. This appear to me to be a variation in a already-existing bug.

In fact, ffmpeg's own definition of the 'aac_adtstoasc' option is:

2.1 aac_adtstoasc

Convert MPEG-2/4 AAC ADTS to MPEG-4 Audio Specific Configuration bitstream filter.

This filter creates an MPEG-4 AudioSpecificConfig from an MPEG-2/4 ADTS header and removes the ADTS header.

This is required for example when copying an AAC stream from a raw ADTS AAC container to a FLV or a MOV/MP4 file.

This doesn't quite tally with what actually happens, namely that the meta-data is copied to the new mp4 container. Also, with the current ffpmeg, the 'aac_adtstoasc' option isn't even necessary - the older ffmpeg throws up an error saying you have to use the 'aac_adtstoasc' option. - and produces playable mp4 containers every time. It's just that it doesn't copy the Title/Artist meta-data over as 'aac_adtstoasc' obligingly does!

Edit: I should add that although the current ffmpeg writes the metadata to the new mp4 container, it also produces an error everytime saying "Error parsing ADTS frame header! Failed to open bitstream filter aac_adtstoasc for stream 0 with codec copy: Invalid data found when processing input". This sounds terminal in nature, yet ffmpeg will still create the mp4 files, many/most of which will playback, some won't. In fact, I've just tried Streamripper-ripped streams ranging from 24kbit/sec to 128kbit/s, and they all produce this error - so it seems that ffmpeg doesn't regard Streamripper-produced streams as valid raw ADTS AAC files to begin with! Given that there are several tickets opened against ffmpeg on this, I'm inclined to suspect ffmpeg itself.

[omelette]

A resolution! It's not pretty but it works, at least on my setup. I use a 'm4a' output extension 'cos my Ubuntu setup won't 'preview' mp4 files. It's easily changed though.

My opinion of ffmpeg has fallen a notch or 10 in my endeavour - the 'fluid' nature of its dealings with aac files has been maddening, of the 3 versions of ffmpeg I've been working with, each produces different results, with the latest & greatest (freshly built from a Github clone) performing worst! In the end I've had to use both Mp4Box and ffmpeg. Mp4Box to copy to an mp4 container that playsback ('cos ffmpeg can't do it without errors!) and ffmpeg to read the metadata & write it back to a copy of the file MP4Box produced. The metadata success is largely thanks to this website.

#!/bin/bash
for i in *.aac
do
ffmpeg -i "$i" -f ffmetadata metadata.txt
MP4Box -add "$i" -new "${i%aac}mp4"
ffmpeg -i "${i%aac}mp4" -i metadata.txt -map_metadata 1 -c:a copy -id3v2_version 3 -write_id3v1 1 "${i%aac}m4a"
rm "${i%aac}mp4"
rm "metadata.txt"
done

[hello_hello]

Thanks for reporting back! I've been away and haven't read through your posts very thoroughly yet, but I will.

[omelette]

Thanks for reporting back! I've been away and haven't read through your posts very thoroughly yet, but I will.

My pleasure. I hope someone else finds it useful, I certainly do! I like to grab different genres of music, say 24hrs worth, from low-bitrate streams and all at one sitting - that way I get a 'snapshot' of what was current at that time! The raw aac problem was a real bitch though - re-encoding 1000's of files which took hours, only to end up with much larger files which were noticeably of lower sound quality was a real bummer.

Two other things I'll should mention. The nightly-release of ffmpeg that I got will by default write the metadata straight to the new mp4 container it creates using line #1 of the first Bash script. No other ffmpeg version I had tried did that. Unfortunately it then screws up big-time, producing many corrupt mp4 containers, with both playable and non-playable producing errors messages! I am in full agreement with the ffmpeg-users that opened bug-reports on this - ffmpeg should not generate files when it insists that it cannot understand the input file, and in practice makes using ffmpeg untenable. poisondeathray's suggestion of mapping the metadata using ffmpeg doesn't seem realisable. When I try using the '-map_metadata' option to do this, ffmpeg insists on re-encoding the input file. Worse, the nightly-build's default compile-settings has it refusing to encode to aac which it lists as "experimental" (in 2014!!!) but does suggest using a switch-setting to bypass this restriction. However, I could not get this to work either...

[omelette]

I wonder can any Bash-expert explain the following problem I'm encountering. Say I have 2 files named 'jack.aac' and 'jill.aac' in a folder and I run the below script on them, I get the expected 2 file-names being displayed. If however I include 'ffmpeg -i "$i" -f ffmetadata metadata.txt' in the while-loop, the second file to be 'read' is missing a character - for instance, 'ack.aac' is displayed rather than 'jack.aac'. This only seems to happen with the ffmetadata line - I can use ffmpeg for instance to copy a raw aac file to a new container while in the while-loop and this 'filename-corruption' doesn't happen. Is this yet another ffmpeg bug or am I just displaying my Bash ignorance?

ls -f -tr *.aac |
while read i; do
echo $i
done

[omelette]

The above problem appears to be Bash-related, or at least it's hard to believe that this could be caused by ffmpeg. So, as I haven't been able to search out a solution to this, I decided a change of tack was in order.

But first, I should explain what I was trying to do. When you create new containers for the raw aac files, all 'modification-date' info of the old raw aac files is null & void for the new mp4 files - this means that there is no way of discovering the original play-order of the files that were ripped, so no way to play them back in the original order either! Well, not quite - there is the track number, which in theory will let you sort the files (if your media-player has a track-field, Decibel has!) in the original play-order. In practice however, I have found that repeated disconnections/restarts of Streamripper means that you end up with multiple same-track-numbers on many songs, either because the station or Streamripper resets the track-count after a disconnection. Whatever causes it, it renders the sort-by-track unreliable at best.

Enter the below script. When creating the new mp4 containers, this will also set their track numbers (beginning at 1) based on the modification-date of the original raw aac files - meaning that by sorting by track number, the original playback-order is preserved!

Ideally, the new modification-date times of the mp4 files should carry the same order - but they don't. The reason seems two-fold. As these mp4 files are created very rapidly, there is very little time-difference between creation times, problem 1. Problem 2 (and probably the main reason) is that probably different CPU-cores are finishing conversions at different times. I thought the Linux 'taskset' command was the solution but many files are still created out of order. Maybe it's because even though 'taskset' limits the script to one CPU-core, Linux may still be running multiple script-jobs on that one core. Dunno, I'm baffled!

The script is a rough & ready affair - just like my knowledge of Bash - so if anyone can improve it, please do.

#!/bin/bash
NDX=1
filecount=$(ls *.aac | wc -l)
ls -f -tr *.aac > lsOutput
while [[ $NDX -le $filecount ]]; do
i=$(sed -n '1,1 p' lsOutput)
sed -i -e '1d' lsOutput
ffmpeg -i "$i" -f ffmetadata "metadata.txt"
sed -i 's/track=[0-9]*/track='$NDX'/' "metadata.txt"
MP4Box -add "$i" -new "${i%aac}m4a"
ffmpeg -i "${i%aac}m4a" -i "metadata.txt" -map_metadata 1 -c:a copy -id3v2_version 3 -write_id3v1 1 "${i%aac}mp4"
rm "${i%aac}m4a"
rm "metadata.txt"
let "NDX += 1"
sleep 0.5
done
rm "lsOutput"

Edit: After a think about it, the only solution would appear to be to include a delay between new-container creations. Setting it at half a second works for me, but needless to say, slows things down! Aww well, they only need to be created once, and preserving the play-order is much more important.