I have successfully fixed the bug in the modified code provided by "danchr".
Fixed -mpeg-version switch also works with AAC extraction from MP4 now!

You can now:

* create MP4 files from ISO13818-7 AAC ones which can be played back by QuickTime 6 and other non-standard compliant decoders and
* extract ISO13818-7 AAC files from MP4 containers with MPEG-4 AAC audio object inside. The owners of a Philips Expanium portable CD player can now also play these files.

just use the new -mpeg-version switch with either the value "4" or "2"!

Regards
Enrico

Where can we find windows binaries of the new version?

Edit: answer: http://rarewares.hydrogenaudio.org/mp4.php. note - entries on page not in chronological order

I just uploaded the latest version.

It would be awesome if this worked, but it isn't for me. I used Ivan & Menno along with this, placed the "-mpeg-version=2" string without quotes into the encoder options, and clicked on Convert. The file I get plays, but is corrupted; the position bar in Winamp stays to the right the entire playing time. I did a binary comparison with my Nero-outputted ISO AAC file that is concurrent with the MP4 file I tried to convert, and it shows up 32 errors. Something is wrong here. I tested that other hacked version of yours, and adding to the unidentical errors to this that I've previously mentioned here and here
this is a turn for the worse.
The second link is where I have made some progress determining if the previously mentioned 31 errors I get with any mp4creator are only present when decoding Nero MP4s, which I think I have come to the conclusion that they are, but have gotten no feedback on the issue.
Now, we have something ELSE going on here with this newest version, like I said, these 32 binary errors start from the beginning of the file and have no correlation to those mentioned previously that only are at the end. But, as such, I would aprreciate BOTH being fixed.
Again, this time, Winamp still thinks it is an MPEG4 stream, so I am thinking that the conversion is not even happening correctly.
A possibility is that the "Convert" button in Ivan & Menno simply does not pass the encoder option string to mp4creator. I did not test in command line yet.

Hmm, have you tried to use the command-line of mp4creator directly?
Ivan & Menno user interface, should be updated accordingly with my enhanced version of mp4creator. Commands in Ivan & Memmo effect only the encoder, not mp4creator. I already sent to Speek, a request to modify his UI. You can do the same. You shoul remind him, that the mp4creator mpeg4 default can be removed, because, it is out of date because it uses the old headers and it is no longer needed with my special version of mp4creator.
command line example:

converting mpeg-2 aac to (mp4 QT6 compatible)
mp4creator60 sample.aac sample.mp4 -mpeg-version 4 -optimize

extracting aac which is compatible with portable players such as philips expanium 301 or 401.

mp4creator60 -extract=1 sample.mp4 sample.aac

Regards
Enrico

I tested both of your commandline examples. Same results.

MP4 (MPEG-4) to AAC (MPEG-2 LC) produces the same results as I got with Ivan & Menno, so it isn't a bug in the frontend.

AAC (MPEG-2 LC) to MP4 (MPEG-4) seems to produce MP4-compatible files, but they are slightly different in size compared to the originals. At least going in this direction, the AudioType seems to be transfering over correctly. I also tested AAC (MPEG-2 LC) to MP4 (MPEG-2 LC) and this seemed to produce useable files as well, though not the same as the original MP4 with just the AudioType changed (which it SHOULD be the same as.)

Sorry I forgot the mpeg version swtch in the example yesterday, so more correctly:
mp4creator60 -extract=1 sample.mp4 sample.aac -mpeg-version 2
I remind you that you do not have to use Ivan & Menno GUI at all, for the time being. It needs to be updated. You must type in the command-prompt for the moment.
Have you tried to use the command-prompt only without Ivan & Menno?

Yeah, I should have noticed that myself. BTW, I've been using the commandline completely, my last post included. That did the trick for MP4 to AAC conversion, the output now matches your originally modified mp4creator's output. As such though, there are still 31 inconsistencies, of which I'd mentioned previously. between Nero and mp4creator produced files. At least we have a more configurable executable and aren't LOSING any ground here. Cheers to that!

As for AAC to MP4, quite apparently, the output does NOT match Nero MP4s. You stated QT6 MP4 as to what this produces, so can I assume that there are slight differences there?

Also, take note of a wierd occurrance: Not only do "Earshot - 01 - Headstrong (Nero Original).mp4" and "Earshot - 01 - Headstrong (Nero MP4 to AAC back to MP4 with mp4creator mod old).mp4" not match in binary comparisons, they ALSO do not compare in filesize. And to top it all off, "Earshot - 01 - Headstrong (Nero MP4 to AAC back to MP4 with mp4creator mod new).mp4" matches neither in binary comparisons OR filesize, and the last two are even converting to MP4 the second pass with the same INDENTICAL AAC file that is produced by each seperately (see above paragraph).
So, has the AAC to MP4 conversion process changed since your last mod? Just to be sure, you DO understand that there would NOT be filesize inconsistencies with simply different AudioTypes, so we should be able to rule out commandlines here and say that something NEW is taking place. Could "-optimize" be the culprit?

About QuickTime player, it only undestand mp4 aac files with an mpeg-4 object inside, not mpeg-2.
The mp4 files are slightly smaller than the corrisponding aac files (usually having an adts headers)
I don't understand very much how you carried out your comparison tests.
Could you explain with more details?
What is the starting file, and what conversions do you perform?

Sure thing. I just finished up school today for the year, so I'll get right on a more detailed explanation. I have come to find that it is very difficult to describe conversion processes easily, but I'll see what I can do. Practice makes perfect. Lol, maybe my lack of communication has been why I haven't gotten any results on the issue!

Ok, I will start from the beginning. I decided to test the Nero audio encoding options a few months ago. I posted to http://www.hydrogenaudio.org/forums/index....=ST&f=13&t=6447 and learned as I went about the MP4 format. After running into a couple of terminology problems, I got through, but HAVE found some bugs in AAC and MP4 conversion between implementations across the board, but more on that later. I learned how to use mp4creator to convert, or extract, MP4 files to AAC files and vice versa. I read about how one could use MP4UI to change the AudioType of an mpeg-4 MP4 to mpeg-2 MP4 and then extract the AAC stream with mp4creator, thereby allowing one to create Expanium-compatible AAC files from mpeg-4 MP4 media.
From here, being an audio perfectionist I guess, I did some tests comparing my different conversion results to see if all files were identical. I found some inconsistencies in the results, and I posted them in the above thread, though I will post the results here again for completeness.

[quote]I tried it. I changed the Audio ID from 64 to 103 for one of my mp4 files in mp4UI. I did not "optimize" anything. Next, I used Ivan & Menno to convert the file. Finally, I compared the original AAC file that Nero created with the one that I just converted in a binary comparison program. The two files are the exact same length, but near the very end, the program picked up (only) 31 mismatches between the two. So this method is doing a very close to perfect conversion, but not perfect. I can email someone the two files if they would like. Here are the mismatches:

Mismatch - Offset 0006407507 File 1 :  File 2 : t
Mismatch - Offset 0006407508 File 1 : File 2 : —
Mismatch - Offset 0006407509 File 1 : � File 2 : Ö
Mismatch - Offset 0006407510 File 1 : ` File 2 : 4
Mismatch - Offset 0006407511 File 1 : ‘ File 2 : 2
Mismatch - Offset 0006407512 File 1 :  File 2 : b
Mismatch - Offset 0006407513 File 1 :  File 2 : ù
Mismatch - Offset 0006407514 File 1 :  File 2 : Í
Mismatch - Offset 0006407515 File 1 :  File 2 : ª
Mismatch - Offset 0006407516 File 1 : ¼ File 2 : ×
Mismatch - Offset 0006407517 File 1 :  File 2 : ¸
Mismatch - Offset 0006407518 File 1 : † File 2 : a
Mismatch - Offset 0006407519 File 1 : Ø File 2 : ¬
Mismatch - Offset 0006407520 File 1 :  File 2 : W
Mismatch - Offset 0006407521 File 1 :
File 2 :
Mismatch - Offset 0006407522 File 1 : + File 2 : š
Mismatch - Offset 0006407523 File 1 :  File 2 : "
Mismatch - Offset 0006407524 File 1 :  File 2 : à
Mismatch - Offset 0006407525 File 1 :  File 2 :
Mismatch - Offset 0006407526 File 1 : Y File 2 :
Mismatch - Offset 0006407527 File 1 : � File 2 :
Mismatch - Offset 0006407528 File 1 : ? File 2 : ,
Mismatch - Offset 0006407529 File 1 : % File 2 :
Mismatch - Offset 0006407530 File 1 : À File 2 : Ž
Mismatch - Offset 0006407531 File 1 : ° File 2 : !
Mismatch - Offset 0006407532 File 1 : H File 2 : 
Mismatch - Offset 0006407533 File 1 : ˆ File 2 : O
Mismatch - Offset 0006407534 File 1 : ˆ File 2 : þ
Mismatch - Offset 0006407535 File 1 : ˆ File 2 : �
Mismatch - Offset 0006407536 File 1 : „ File 2 : 7
Mismatch - Offset 0006407537 File 1 : \ File 2 : ÿ


Edit: btw, file 1 is the original mp4 mpeg-4 AAC LC file (created by Nero) converted to mpeg-2 AAC LC with mp4UI and Ivan & Menno. File 2 is the original mpeg-2 AAC LC from Nero. [/quote]

The feedback I received was on the lines of "Do you notice any difference between these files? I wonder what are those mismatches, but, if they don't f*ck up your file, I think you don't need to worry. " That was not my intent, and as I have come to find on this board, we enjoy getting things exactly right.
I next got some ideas from Ivan Dimkovic, the Ahead MPEG4 developer. He figured that "maybe [the] ADTS headers are just different and there is no spectral difference," which I think is right, I remember comparing just the audio streams, with no differences found. I haven't sent him the files yet as he suggested, I may if I don't get any feedback this time around.

At this point, enry2k posted info on his first modified version of mp4creator (which he emailed me) which forced an mpeg-2 AudioType when converting files with the program, allowing one to skip the mp4UI step and batch create compatible Expanium AAC files from mpeg-4 MP4 files with no other software needed. At that time, I compared doing the "hack" the old way and the new way, and both created identical results, fyi.

After that, I got no more posts regarding the binary differences between Nero output and mp4creator output, and I left it alone until I read another post on this board that got me thinking of a possible reason for the differences.

So, I posted my results there http://www.hydrogenaudio.org/forums/index....ST&f=13&t=8541& . Though slightly off topic (the thread there was more interested in going from AAC to MP4), I posted anyway, as it had got my mind going on an idea. Here are my posts there (they kind of got lost in the on topic discussion so I have reposted them here):

[quote]
I remember in a previous thread http://www.hydrogenaudio.org/forums/index....3&t=6447&hl=mp4  where I was having issues going the other direction (MP4 to AAC).  This thread made me think back to something and I have a theory of what could be the problem.  What I was getting before were small binary differences between "converted to MPEG-2 AAC from Nero MPEG-4 MP4" files and the original ISO MPEG-2 AAC files created by Nero, but the audio itself was staying completely the same.  Could we have garbage being left over because of a slightly outdated header compatibility when processing and converting the Nero MP4 files to MPEG-2 AAC files through either a combination of mp4UI and Ivan & Menno or enry2k's modified mp4creator.exe (these in themselves produce identical results)?  From how I understand it, the MP4 header is being removed, and we are forcing an MPEG-4 object type, that's all.  There is no "interpretation" of the MP4 header when converting.  So, when I read this: 

[quote] And you should keep an eye on any new mp4creator version that might appear on RareWares in the future, because it seems that v0.9.8 still has not implemented the last MPEG revision of the MPEG-4 AAC LC ADTS header. [/quote]

it hit me that maybe the slight difference is being caused by a misinterpretation of the header information because of slightly outdated MP4 header spec compatibility in mp4creator compared to Nero. As such both the addition AND possibly the removal could be just enough off of spec to cause a discrepancy. If Nero is using a slightly newer MP4 header configuration that is slightly clashing with how mp4creator handles its removal, this could be the problem. Yes, of course these end files both still function, and like i've said before, maybe this is seeking perfectionism, but that is what this board seeks, so I'm putting it out there.
What I'll do to test this is start with a clean AAC, convert to MP4 and then back to AAC, and see if I don't get identical results within the confines of enry2k's modified mp4creator executable.
Thanks
[/quote]

hans-jürgen responded:
[quote]
[quote=mmortal03,Apr 22 2003 - 03:24 AM] From how I understand it, the MP4 header is being removed, and we are forcing an MPEG-4 object type, that's all.  There is no "interpretation" of the MP4 header when converting. [/quote]
No, mp4creator isn't forcing the MPEG-4 AAC LC Object Type while extracting, it's only copying the "MPEG-x" flag from the MP4 header to each ADTS header that gets inserted in each frame of the extracted AAC file. So if there was a MPEG-4 flag in the MP4 header, this caused an MPEG-4 ADTS header which meant 2 additional bits for the emphasis field until December 2002. If there was a MPEG-2 flag, this emphasis field wasn't used in the ADTS header. See http://www.audiocoding.com/wiki/index.php?page=MP4 and also the ADTS page for more information.
[/quote]

I responded:
[quote]
[quote=hans-jürgen,Apr 22 2003 - 10:16 AM] [quote=mmortal03,Apr 22 2003 - 03:24 AM] From how I understand it, the MP4 header is being removed, and we are forcing an MPEG-4 object type, that's all.  There is no "interpretation" of the MP4 header when converting. [/quote]
No, mp4creator isn't forcing the MPEG-4 AAC LC Object Type while extracting, it's only copying the "MPEG-x" flag from the MP4 header to each ADTS header that gets inserted in each frame of the extracted AAC file. So if there was a MPEG-4 flag in the MP4 header, this caused an MPEG-4 ADTS header which meant 2 additional bits for the emphasis field until December 2002. If there was a MPEG-2 flag, this emphasis field wasn't used in the ADTS header. See http://www.audiocoding.com/wiki/index.php?page=MP4 and also the ADTS page for more information. [/quote]
I haven't had time to test my theory yet, but I will. Thank you for the clarification. One thing I think you might have missed though. I am refering to a modified copy of mp4creator that forces all mpeg-4 audio contained in MP4 to the mpeg-2 AAC object type. This works the same as changing the object type in mp4UI and then running the MP4 through an unmodifed copy of mp4creator, but is of course with less steps and is batch . I am sure you are refering to the unmodified copy when you state that the program is simply copying the data over, as it should work normally, I assume. Can you clarify?

Edit: flip flopped some mpeg-x's because of inconsistency.
[/quote]

hans-jürgen:

[quote]
[quote=mmortal03,Apr 24 2003 - 06:49 AM] I am sure you are refering to the unmodified copy when you state that the program is simply copying the data over, as it should work normally, I assume.  Can you clarify? [/quote]
Yes, and please don't spread this enriconized mp4creator version all around now. He already promised to mail Bill May his changes, so that there will be an official MPEG4IP version probably soon. See this thread in the QuickTime forum:

http://discussions.info.apple.com/WebX?14@...kyV.0@.3bc08671
[/quote]

me:
[quote]
[quote=hans-jürgen,Apr 24 2003 - 01:11 AM] [quote=mmortal03,Apr 24 2003 - 06:49 AM] I am sure you are refering to the unmodified copy when you state that the program is simply copying the data over, as it should work normally, I assume.  Can you clarify? [/quote]
Yes, and please don't spread this enriconized mp4creator version all around now. He already promised to mail Bill May his changes, so that there will be an official MPEG4IP version probably soon. See this thread in the QuickTime forum:

http://discussions.info.apple.com/WebX?14@...kyV.0@.3bc08671 [/quote]
No problem; yeah, I definately won't spread it around. Sounds great that we will get an official version soon.
[/quote]

and me again:

[quote]
[quote=mmortal03,Apr 21 2003 - 07:24 PM] What I'll do to test this is start with a clean AAC, convert to MP4 and then back to AAC, and see if I don't get identical results within the confines of enry2k's modified mp4creator executable.
Thanks [/quote]
I just tested it. The original aac file in the test and the aac->mp4->aac file in the test are identical. This means that Nero is using some sort of slightly different MP4 container format (or something other) than mp4creator. The 31 differences are stemming from converting Nero MP4 to AAC, so there you go.

BTW, a new mp4creator was released recently. IIRC it is the one in the updated Mp4UI package at Rarewares. This update to compliance does not fix this issue of 31 binary errors when converting Nero MP4's to AAC, so I assume they are completely unrelated.
[/quote]

That is where it stood until this thread. Hopefully, that will bring you up to speed.

I'll post more thorough descriptions of my tests and conversions from this thread in a minute.

Now that a new version of enry2k's modified mp4creator came out, I jumped right on it, because he said that now the AudioType change would not be hardcoded; You can now choose whatever AudioType you require when converting, simply by changing a switch in the program. VERY nice! So, I sat down and tested this new version and compared it to my previous results, still wanting feedback on my above findings and wanting to know if this bug was somehow fixed. After getting past some commandline roadblocks, I came up with identical MP4 to AAC conversions compared to before, but with the same old problem. 31 binary differences at the end of the resultant AAC file when compared to Nero's AAC output. This has not changed. Please refer to the above information for insight on this. This is my original problem which I would like to see fixed. It is an apparant difference between Nero output and mp4creator outputs, and it is the same across the board when comparing MP4 to AAC conversion results to Nero's originals. This is again my main concern.


Within THIS thread though, I also noticed that AAC to MP4 conversion has apparantly changed slightly between all three builds, unless there is still some sort of commandline error in my tests, and I doubt that. The three builds of mp4creator tested are:
enry2k's original mp4creator modification, based off of an older mp4creator version,
the newest official mp4creator build from Rarewares,
and enry2k's newest mp4creator modification, based on the newest mp4creator.

Whether or not QT6 has anything to do with it or not, I still haven't gotten a clear answer. From what you say enry2k, I assume you are just using "QT6-compatible" to denote mpeg-4 AAC stream MP4 files. That is how I understand it.
I do understand that the MP4 files will be slightly smaller then the AAC files, and that is NOT what I am comparing. I am comparing MP4 files to MP4 files, and the size difference is very slight.

The starting file isa Nero MP4 encode of a wav file called "Earshot - 01 - Headstrong.wav". I have labeled the encode as "Earshot - 01 - Headstrong (Nero Original).mp4". It is an mpeg4 AAC stream inside the MP4 container.

Here are my testing steps:
First, I take the MP4, use mp4creator to extract the AAC stream, using this commandline:



Next, I take the resultant sample.aac file and re-encode it to MP4 with this commandline:


Finally, I compare the resultant sample.mp4 file to the original "Earshot - 01 - Headstrong (Nero Original).mp4" with a binary comparison program.
They are not the same, not even in filesize. I open the sample.mp4 file in MP4UI, and find that there are two extra tracks. One is named OD, and one is named BIFS. This could be the inconsistancy in filesize.

Furthermore, I go through the same conversion process with the older modification and compare this sample2.mp4 to the new sample.mp4, and it too has the OD and BIFS tracks, and of course they are the same size. I check to make sure they are the same AudioType. Yes, both are mpeg-4 audio streams. When comparing these two in the binary comparer, there are 10 differences at the very beginning of the files.
I next remove the OD and BIFS tracks from both sample.mp4 and sample2.mp4 with MP4UI to see if this is the reason for file size inconsistancies with the original MP4. It isn't (or isn't the whole reason). While both sample.mp4 and sample2.mp4 still match in filesize after the extra track removals, they DO NOT match the original in size. FYI, without the extra tracks, sample.mp4 and sample2.mp4 STILL contain 10 differences between them at the beginning of the files, whether I choose to optimize them or not.

For kicks, I took the Original Nero (ISO standard) AAC and converted it to MP4 with mp4creator. It does not match either the Original Nero MP4 (even after removing the OD and BIFS tracks) nor does it match either of the mp4creator re-conversions of the original (sample.mp4 and sample2.mp4).

I also used the new official build of mp4creator (mpeg4ip version 0.9.8.4) as well and re-converted to mp4. I named this sample3.mp4. It is different in filesize than all the others as well, and I made sure it was the same AudioType, so there you go.

My thoughts on the 10 differences between mp4creator mod 1 and mp4creator mod 2 is that it might be related simply to that latest bug fix from the other week.

Hopefully, we can get this all fixed!

I have followed your procedure, the outcome is that aac files are binary identical, but mp4 are not. I think this depends on the implementation. Nero probably uses slightly different parameters than mp4creator.
About Quick Time 6. The latest version 6.1 produces mp4 files which are fully understood by mp4creator, while the previous version 6.0, used a different coding of number of audio channels called AES which were read always zero channels. This was a problem when reconverting back to mp4. Now they used the most common solution like nero and mp4creator, so the problem is resolved now.
As I told you before the QT6 player still doens't support mpeg-2 aac objects in mp4 files.
Regards
Enrico

The AAC that Nero produces in NOT identical to the one produced by mp4creator, there are 31 binary differences between the two at the end of the files. When it is so little, I can only imagine some sort of tagging, fingerprint, or watermark, or simply trash at the end of one file that isn't there for the other. The audio streams are identical, so I want to find out what this "trash" is. If they are identical audio streams, then in my opinion they should be identical files. In this case they are not. As for your conclusion that Nero probably uses slightly different parameters than mp4creator, what could they be if not related to audio?
If you only meant it regarding MP4's, well, we can start by noticing these OD and BIFS tracks, created by mp4creator, what are they? After deletion of these though, the MP4's are STILL unidentical. I wonder what is different THEN? All that should be left over is the audio stream enclosed in the MP4 container. Are there some sort of tagging differences in the MP4 containers used by Nero compared to mp4creator, or is there simply garbage in one that is not in the other? If this is such a little difference, what is it? Not being my only reasoning, but this makes it hard to find duplicate encodes and make easy comparisons of identicality across the board, especially when there is something being done differently in a supposed standard. I always have liked to know WHY something is different if there is no need for it to be.

Well, I DID make some progress today. I found that the CreationTime and ModificationTime information on the MP4 files that were of different size were off. So, I picked some arbitrary number to set these to in MP4UI, set the values for both files, removed the OD and BIFS tracks, and then optimized both. They are still off by some odd bytes, but I AM getting closer. Does anybody know of anywhere else to look in the files for differences (with another program) without have to resort to a hex editor or the like?

Here are the file sizes right now (btw, both of these have identical audio streams):
6,371,710
6,371,682

Edit: I did it again, starting with clean files, and duplicated those file size results. but, for some odd reason, I got 10 mismatches here at the end of the files. I will do a third test and see what happens...

Edit2: I retested, found my error. With three separate tests, I verified the filesizes
6,371,710
6,371,682
and found that within each filesize there was a slight 3 mismatches between each when binary compared. I think this may have something to do with the hint track naming incrementation that is automatic in MP4UI. I add and then remove a hint track for each so that I can then optimize the file before going to the next in my process. I will increment them all to the same number and see if this sheds any light on this.

Edit3: I was right. MP4UI saves some type of history to each MP4 when creating a hint track. When I incremented the "history" of created hint tracks to 9 for each file, I knocked off some of the binary mismatches. Besides one odd file which is off by 2, the binary mismatches for my three 6,371,710 files and my three 6,371,682 files are down to 1 mismatch between each. Anybody care to tell me what this last difference is? Also, I still don't understand what the difference between my set three 6,371,710 files and my set three 6,371,682 files are. This still stumps me.

After replacing in_mp4.dll with the newest version, all my Psytel 2.25 mp4
files (created using ivan&menno frontend and an older version of mp4creator)
don't play in WinAmp. Well, they appear to be playing, but u hear static!
I thought that I read somewhere that the latest plugin is not compatible
with mp4 files created using older versions of mp4creator, so I used the
ivan&menno to turn my mp4s back to aacs, and then back to mp4s using
the latest mp4creator. Unfortunately I ended up with corrupted files
which WinAmp refuses to play (as does fb2k), and to make things worse
if I turn them into aac again, the aac files are corrupted as well (WA and
fb2k report bitstream errors). What can I do to make my old mp4s work
with the new WinAmp plugin?

Anyone?

Ditto.