btw check your mail

And that's what prevents us from moving forward.

Many advocates of metadata implementations realize that abandoning filename extenstions completely is unrealistic in a cross-platform environment. The argument then is to convince people of the value of metadata over filename hacks in the hope of one day making some forward progress.

First of all, the first wide-spread implementation of the MP4 container was QuickTime 6, and it used MP4 for content played back in QuickTime Player. A player mainly for video. Second, M4V seems to be used for MPEG-4 Video Elementary Streams - according to this mail, and that's how FFmpeg and friends have used it for quite some time.

The best extension would probably have been .aac, but that one wasn't available

[quote=danchr,Jan 12 2004, 02:36 AM] [QUOTE=spoon,Jan 11 2004, 02:43 PM]The best extension would probably have been .aac, but that one wasn't available [/quote]
Then what would we use for AAC files not in an MPEG4 container?

Erm.. we are exactly talking about AAC inside the MP4 container.

Sorry for waiting so long to reply. This thread slipped under my radar.



I didn't think I was unclear. danchr implied that we should have .aac as the extension for aac files in an mp4 container. But then what would we use for aac files not in an mp4 container?

This is a reason for not using .aac.

Thoughts on metadata:

Metadata as filetype and other such thing is a good concept, but it needs more than what exists to implement it properly. Primarily:

1. Metadata needs to be filetype independant. That is, it needs to be the same structure for every file, regardless of type. Otherwise you're essentially just deriving the filetype based on file content, and that just doesn't work.

2. Metadata needs to be part of the file itself, not stored in some hidden place. In a file transfer, generally the file is sent. If the metadata is not part of the file, it may not be sent. Separating metadata from file content does have it's advantages, but it also makes it easy to lose the files metadata using existing file transfer systems.

3. Metadata needs to be *easily editable*. I know a lot of people have said that it's too easy to change a file extension. Well, in the one highly common metadata scheme I've seen (Old MacOS versions), you needed a freakin' undocumented tool (ResEdit) to change the filetype. That's unacceptable and one reason I switched from Macs to PC's in the first place. PC's let me get things done my way, Macs made me use their way. If I can't change something like the filetype easily, then it's the system is broken.

4. Metadata needs to be easily extensible. This is easy to do, and although it will lead to different naming systems at first, a standard will build itself up over time and the system will evolve into something more useful. A standards body could control the "offical" named metadata types easily enough. But unoffical metadata fields are essential for proper growth.

Tagging schemas that have evolved like ID3, APE, etc are starting to point the way in this regard, I think. If a standardized file tag structure existed that could hold any given metadata like this, and standard things like filetype and such were defined in there, and support was added to the major OS's to read them and either ignore them or act on them transparently to the underlying applications, then the concept would take off in a significant way. In other words, if Windows supported it (which would take some doing), it would get big. Linux would obviously support it earliest, and probably a fairly minor kernel patch could do it too. But it'd take off eventually.

You want backward compatiblity? Easy enough to do... You strip the metadata off the file at the filesystem level and provide new functions if apps want to access that metadata. In other words, when you fopen() the thing, you only get back the file content on an fread(), not get the metadata even though it's part of the file. As support grows on Linux and such, small programs will have to be written to strip the metadata for Windows compatibility until MS adds support for it, but it'd happen eventually.

Ah, I see.

I guess his point is that containerless AAC shouldn't even exist. Or should be treated like a .raw file.

Why would you want to change the type of a file without changing the file itself? A jpeg is a jpeg; an mp3 is an mp3. There's no way to change that without modifying the file.

What you want is an easy way to change what the OS does based on the file type. This comes from Windows where the filename extension, and thus the file type, is associated with a specific program. There's no reason this needs to be the case.

using MP4 here, mainly because:
0) Compaact! uses it
2) Compaact! has excellent low bitrate sound (30-40 kbps) on my preliminary tests (edit: using quality 0 VBR settings - all of those files were mono Radio recordings from 1930-1960) and also sounds transparent to my ears with what I have encoded so far on the quality 6 VBR setting
3) and the biggest one - I can use compaact! thru the foobar 0.7 diskwriter to encode a large group of files at once. The program's gui interface seems to be lacking there unless I am missing something.

Regardless of how you define a file type, be it metadata or be it file extension, there will always be application associations that are linked to that file type.

Often, the easiest way to change which application a file uses is to change the file type. Many formats are not all that different, and that's becoming more and more the case as formats become plaintext for interoperability.

Say I have an XML file. If I want to open it in a text editor, I can change it to a TXT file type and simply open it. Maybe I don't want to open all my XML documents in the text editor all the time. Maybe I just want to open it in the text editor quickly. Maybe I'm going to remove all the XML and just keep part of the file. Who knows? That's for me to decide.

Frequently, I work with Tab or Comma Separated Value files. I can open these in my spreadsheet program if they are a file type TSV or CSV, respectively. But if I want to combine some data from multiple files, the fastest way is for me to change them to text, open them in a text editor, copy and paste the data from one to another, then change the file type back to what I want it to be.

Just because you use your system one and only way doesn't mean that others do too. The need to change file type for a given file is essential, or the structure is broken. Whether you do it by renaming the file's extension or by changing the metadata using a metadata editor of some type is irrelevant. But it must be *easy* to do or the utility value of changing a file's type is lost.

There's other good reasons to do this too. I have a text editing program with a really nice hex view mode, if I open a binary file. But it only activates that mode when the file type is a binary type, like EXE. Often I want to view a file in that mode. Easy solution, change the file type to EXE and drag it in there. Done and done. The application is poorly designed in this respect in that there's no other way to activate this mode, but applications will always be poorly designed in some respects.

Yes, the file type is supposed to define the type of data contained in the file, and I agree that there should be no reason to change it, in a perfect world. But the world is imperfect, and application associations to filetype will always exist because they make life easier, in most cases. If you have a better way to accomplish the goal, let's hear it.

Have you ever used OS X?

Each application registers with the OS what file types it can handle. The user can set default handlers for each file type. The user can also specify which application should be used on a per-file basis. Furthermore, by right-clicking on a file, the OS shows an "Open With..." contextual menu (similar to Windows) that shows each of the applications that are registered for that file type. Files can also be dragged onto the application icon to open them. This, of course, overrides any default setting and tries to open that file with that application. Note that all of this is done without the need of the user to ever change the file type.


Yes, and there's no reason for only a single application to be associated with that type.


The system I outlined above handles all these cases perfectly without the need to change the file type.


Why the need to change the file type to text? If a text editor can open the file, it will. This is handled as I said above, by dragging the file over the icon of the application.


Rather, the need to change the file type is a symptom of a broken implementation.

Yes, I have. I hate the OS X model.

For one thing, I dislike keeping icons of my applications around on the desktop to drag files onto. It's cluttered and ugly. Furthermore, at a quick count, I have 90ish applications on my system, of which 60 or so I use on a semi-regular basis. Ever try to search through 60 icons for the one you want to find?

For another thing, I prefer that most things I use be full screen, so I can see what I'm doing and maximize my use of the screen real estate. So having icons on the desktop that are not immediately visible makes it kinda hard to drop files onto them. (Edit: Side note, that one of the first things I hated about iTunes for Windows.. First time I ran it, the first button I clicked was the "maximize" button. What does it do? It goes to a mini window mode. Not a good first impression for Apple's UI team, let me tell you..)

Third, I only gave examples of instances in which I'd want to open a file using a different applications on a temporary basis. My mistake. There's many instances in which I want to change a file's type permanently. Like when I change an XML file into an HTML one using various methods. Perhaps I don't wish to open it in a text editor and then save a different file out. Or when I change a text file with pasted code into a .c/.cpp/.h file for compiling it or some such thing. Or whatever, the point being that changing the file type is a common occurance, for loads and loads of reasons.

All the things you mention are also available in XP, with the exception of changing default application on a per file basis. Drag & drop files onto app icons is there. Contextual open with menu is there. Applications able to register which types of files they can open and multiple types existing per file is there. I don't *need* to change the file type to accomplish many of these tasks, but I do because it's *easier* than any of the ways you mention. Making things harder is not what a good OS does. Heck, I consider that even right click context "Open With" is harder than simply using the keyboard for a quarter of a second. Open With involves more hand-eye coordination and complex thought than clicking and typing for a fraction of a second and hitting Enter twice. The vast majority of my work involves the keyboard, as using a computer should. Mice are kludgy input devices, at best.

The way you use your computer is *your* way, is the point I'm trying to make here. I prefer to use a different way. And part of my different way is to change filetypes whenever I damn well please. If the OS won't let me do that, then the OS is broken, and I will not use it.

Who said anything about keeping applications on the desktop? I have absolutely zero on mine. All open applications have their icon in the dock, onto which you can drag files for opening. For quick access to applications that aren't running, my favorite method is via a product called LaunchBar. I have over 100 applications on my system, and all of them are accessible with about five keystrokes. No searching through menu upon menu of applications in the Start menu or hunting all over the desktop.


The dock is always accessible, similar to how Windows' TaskBar is always accessible. This has nothing to do with how much screen space your windows take up.

Besides that, having all windows maximized is a waste of screen real estate. An application should only take up as much space as it needs to display its content. My favorite example is browsing maximized with huge white areas to the sides of the content.


Here we agree. But I submit that the file type for all those things is plain text. More metadata should be available to say that the file contains C code or HTML so that the proper application associations can be made. I don't think any current systems get this right.


Well, Windows is making it harder for you than it needs to be.

Let's try an example of opening an HTML file with a text editor. On OS X, you'd just drag the file's icon over the text editor's icon in the dock. If the text editor isn't already running, you'd have to launch it first, preferrably using a quick-access method like Launchbar.

On Windows, you have to change the filename extension to txt. Then it will launch with your default text editor. But the worst part is that you have to remember to change it back afterwards. Even though the text editor is completely capable of opening the file, you have to change the file's attributes for it to work. And then the user is responsible for undoing the damage.

I guess it comes down to this: if the text editor is completely capable of opening HTML files, why should the user have to do these tricks with file name extensions to get it to work? The OS should be smarter than that.

Don't claim things you don't know.

You can do almost the same thing in Windows as you do on OS-X. It is not possible to drop a file directly on the icon in the taskbar, but you can drop it on the application itself. (And the application will be visible if you drag an object over the icon in the taskbar.

There is no need to change any extension in Windows, if you don't wan't to! The only reason to do that is if you wan't to be able to double-click on the file to open it.
The way Otto42 used it seem very inefficient.

But I do agree with you that using the extension to describe the file-type, is bad.

I have never used any Mac system (nether OS-X nor any older system), so I don't know how it works there. Perhaps it is done better then in Windows (I hope). The Unix way with a description tag in the beginning of the file is a quite good system. It is a little more work for the file-system if you wan't the files sorted by filetype or something like that, but I don't know any better system.

You can however drop a file onto an icon in the quick launch bar. But my preference is right click "open with". Two quick clicks and your done. I've always hated the OSX way of doing things.. my arm gets too tired from dragging everything all over the freakin' desktop.

Please. Let's not even get into the travesty of User Interfaces that is the Dock. Worst design ever.


Windows taskbar slides off the screen when I'm not using it. Like I said, I want the whole screen visible and available for use.


Fair enough, except that it's *extremely* rare that I use an application which doesn't have content enough to fill the whole screen. I'm not talking about Word or some such thing where you get white space margins. And I'm not talking about Explorer, where you may not have enough files to fill the window. Those sort of apps I use windowed when I'm using them. But nearly everything else I use has loads of content there, and I want to see it all. So it gets maximized.


Whoops, you forgot that I dislike the mouse and drag and drop.

I can drag and drop files now. I hate doing it. It's too much arm movement and hand eye coordination skills required.

Here's my way. I click the file's name and wait a second. I press 9 buttons on the keyboard in rapid succession. The file opens using whatever app I've changed it's extension to. The process takes under a half a second, total. It requires zero thought, zero effort.

I've been using a keyboard for 21 years. I'm very good at it, as most people are. Why people eschew the keyboard so much is a mystery to me... It's a very handy tool, you know.


No, I could easily right click and use the "Open With" menu, or I could drag it to an icon in the quick launch bar or on the desktop or anywhere else. I don't do that because those are too slow.


The OS can be smarter than that, certainly. But no way you've thus far mention is faster than my nine presses on the keyboard, which requires less hand movement, less coordination, less thought, and less effort than any other existing way of doing things.

This thread is starting to sound like a OSX versus Windows thread

Heheh.

Back on topic: I vote for M4A. It makes more sense to have a distinct audio filetype because of the limitations of existing OS's.

We finally agree!!!

I'll be happy to post a rebuttal to the above comments if anyone's is interested (doubtful ). Otherwise, it's way off topic, so I'll refrain.

To whom it may concern:

I have been reading HA for along while and finally felt compelled to register just to comment on this debate. I am pleading this case for the average person out here. Many of you seem to be industry insiders, and consequently are movers and shakers in the field.

First, let me say I am probably not even qualified to post here. I am merely an avid consumer of digital music, but probably a little more informed than some. I have an iPod and I use iTunes, and I try most all of the other "consumer-friendly" type ripping / burning / jukebox apps. I've also had several other MP3 players from different makers.

Here is what I want to say regarding MP4 vs M4A

PICK ONE!!!!!!!!!!!!!!!!!!!!!!!!!!Seriously, for me, and I think the average person, it doesn't matter which one. Just pick one! It is important that the industry decide on one quickly so we are not all confused. It took me two months of reading before I finally understand all this AAC/ MP4/ M4A business. There is no hope for the average person to understand it if the industry people can't even decide.

Everyone understands MP3 and WMA. Hardly any average person understands anything about AAC/MP4/M4A This will prevent people from using it because it is too difficult to understand.

Fortunately, for iPod/iTunes users, Apple made it easy, and just said "here, just use this, its better" so at least they make it simple. But I think its still very confusing when all these different players. Real, Winamp, Nero, DB poweramp, cannot even settle on a file extension.

Again, I don't care which one it is. I just think it is important for the industry to adopt a standard so consumers can understand. Pick one and stick with it.

If I was forced to pick one, I would say .M4A at this point, since probably most people who have encoded with AAC codec so far used iTunes and created .m4a already for the last year. And things seem pretty simple about .wma and .wmv

That's all I have to say. Now, go move and shake!

Thanks.

I totally agree with you. For me, this .MP4/.AAC/.M4A (and soon .RA or whatever with AAC streams in them) business isn't really a problem. But for the average Joe.. don't even think about it. He wants ONE format (read: extension), not several formats in one .extension (MP3 in MP4 containers for example, which is utterly ridiculous), or the same formats in several .extension.

.WMV = everyone knows this is a video file
.WMA = everyone knows this is a audio file
.MPG/MPEG = everyone knows this is a video (maybe with audio) file
.MP4 = no-one can really be sure what this is, video, audio, audio+video, MP3 stream in a MP4 container, etc
.M4A = everyone knows this is a audio file
.M4V = everyone knows this is a video file

and the perfect thing would be to have .MP4 has a video+audio file, although this might confuse some users thinking that this is "the next mp3".

Also i dont want my video player (i dont use the same player for audio and video, and never will) to open .mp4 files as video files when they contain audio. Nor do i want my audio player to open .mp4 files when they are infact video(+audio) files. with .m4a i could just set my audio player to open the files with that extension, and do the same thing with .m4v (or .mp4) for my video player.


Why the hell not keep it simple (when it works).

Well here is a thread I started a few days ago that answers the problem with the same file format with 2 different extensions, namely .m4a and .mp4:

http://www.hydrogenaudio.org/forums/index....howtopic=18542&

Hopefully software developers will begin to support both file extensions, as currently some programs use one and others use the other one. It is time for the fragmented player/encoder support to rally behind both for compatibility sake.

Here is where we stand currently on file extension support with the major software applications:

Thankfully Ivan at Nero said he will see what he can do about adding an option for the user to select the .m4a 4extension. He and Menno just recently added .m4a file reading/decoding support to Nero with the latest Nero update.

Also the newest beta version of Compaact! supports both file extensions and that feature should appear in the next 1.20 release. Thanks to Alexander for adding that support.

WinAmp currently plays back both .m4a and .mp4 audio files and encodes/rips with a .m4a file extension.

Apple iTunes encodes to .m4a and plays .m4a best (properly recognizes .m4a files as audio). It will play .mp4 files but thinks they are video files sometimes. Apple iPod plays .m4a files.

Foobar2000 plays both formats.

dbPowerAMP converts between both formats/extensions.

FAAD2 supports playback of both formats including HE AAC file playback. It is found as a standalone Windows program, WinAmp plugin and in various other formats.

Hope this helps explain where we are at with MP4/M4A support in apps.

Well, to me, Average Joe, I don't understand supporting two different file extensions if they are the same thing. It is just confusing.

Thanks for the explanation. But it should be easy to understand without explanation.


p.s. ditto the above comment regarding using different media player for audio vs video. I use iTunes (at least currently) for audio and WMP for video.

Well I wish there was only one format defined for MPEG 4 Audio files, but unfortunately they lumped everything togther in the MPEG 4 Container File Format and gave it a default .MP4 file extension.

Apple then later saw a need to differentiate MPEG 4 Audio only files, and started using the .M4A extension for unprotected content (content people encode that will run or can be edited on any computer) and .M4P for their own protected content (DRM, audio content that is limited only to run on registered/licensed computers).

So a good rule of thumb is:

.M4A = Audio file only
.MP4 = Unknown what is inside normally (could be audio, video or mixed audio/video)

*With the advent of more and more video files using the .MP4 format, it will get harder to tell apart MPEG 4 Audio only files from Video files. This is another good reason to start using .M4A so as to not confuse your video/audio players.

I personally think Apple got it right by using one file extension exclusively for MPEG 4 Audio (.M4A), but unfoprtunately many non-Apple encoders started using .MP4 for encoding MPEG 4 Audio files, hence we now have two different filename extensions for the SAME audio file format/content. You can rename a pure MPEG 4 Audio file from .mp4 to .m4a and it should play Ok in your iTunes.

It all comes down to the naming of the file extension issue. This poll clearly shows that people are about 50/50 mixed on which one they prefer to use (M4A or MP4).

I proposed the solution found in the thread linked to above to get software developers to support BOTH file extensions with an option that you the user can select which one your prefer to use. This will get rid of the annoying manual file extension renaming that has been been forced upon us up until recently.

Now most of the MPEG 4 Audio encoding and player programs should be soon (if they are not already) supporting playback and/or encoding of files with EITHER the MP4 or M4A file extension. This poll has helped to show that BOTH file extensions are commonly used by users, and therefore all programs should support both extensions to better please their users. Hope this explanation helps.

So, if I encode with some program that makes .mp4, will they play on my iPod?

Thanks.

You will likely want to rename your .MP4 files to .M4A to take best advantage of playback in iTunes. The iTunes software requires the .M4A file extensions for MPEG 4 Audio files to be able to upload them to your iPod.

The easiest solution for you to avoid the file extension renaming issue would likely be to get encoder software that has an option to produce iPod/ITunes compatible files saved with a .M4A file extension...

WinAmp 5.02 will currently rip/encode files from an Audio CD with a default file extension of .M4A

Nero 6 developers are considering adding the ability for users to select an option to save files with a .M4A extension. Nero (latest update) just added support for reading/playback of files with a .M4A extension by the way.

Compaact! 1.20 release version should have this feature to save file with .M4A extension. The current beta version of 1.20 has this feature.

Hopefully the new Real Player 10 Gold (non beta) will play back and encode HE AAC files using BOTH .M4A and .MP4 file extensions also.

I give up. I don't wanna have to do all that.

I read all of the philosophical discussion about why some people think this one or that. I can see both sides.

But from an average user standpoint. None of it matters. Give me one standard that is easy to use and understand.

I don't want to have to worry about picking which file extension to use and then have to convert them for different players. What if I want to have two different portable players. What if one likes .m4p and the other requires .m4a.

Its all a bunch of nonsense. If thats the path the industry will take, its a dead end.

Its already bad enough we have to navigate the MP3/WMA/AAC thing, much less the fact that AAC standard appears to not even be a standard. Do you think I could even attempt to explain all this to my gal next month when she gets an iPod mini? Yeah, right...

Just use iTunes to encode then, and save everything in .M4A format and you will be happy (and your gal friend too) with playback in your iTunes software and your iPods (and Ipod Mini). That way you don't need to rename anything.

I understand your frustration. I have been trying to inform the audiophiles and software developers of this dual filename issue, but the response I have gotten has mostlly been that not suporting both filename extensions was "no big deal".

But I knew that there would be millions of people just like you, podunk, that would get an iPod or a PC loaded with iTunes who didn't want to fuss with or learn how to rename the files they encoded with other software from .MP4 to .M4A file extensions. Soon, hopefully, all audio apps should be able to save to the .M4A file extension to support the broadest level of compatibility between different audio software programs

Thanks for posting your comments/gripes about the 2 file extensions here. Many audio software developers regularly read posts on this forum. Your poll vote and comments do matter, and I'm sure won't go unnoticed.

Please don't give up, but try to bear with the AAC format (.M4A files). You'll be glad you did. It is a very nice audio encoding format. Enjoy your iPods.

Does it make sense to distinguish between different types of content in MP4 files anyway? There are many different MPEG audio formats that could all be used in an MP4 file, so even for a .m4a file you couldn't be sure whether it carries AAC or something else, and whether it's supported by the associated application or not.

Btw, the forthcoming lossless MPEG-4 ALS codec can also use MP4 files.

The iPod will play .mp4 no renaming and every other uploading program except iTunes is happy (AFAIK) uploading .mp4 to the iPod

My point exactly.

Again, if it has to be explained it is too complicated. The industry needs to pick a standard.

Again, I don't care which one. But there needs to be just one.

And it seems to me that by default .m4a is already the standard of the common man. It seems many of you here use a variety of high tools, but the regular folks like me use iTunes and Winamp. iTunes started the widespread adoption of AAC and they called it .m4a. I think there are way more iTunes users making AAC doec than any other.

Its too late for philosophy. Lets deal with reality.

That's all I have to say. I promise. I'm not asking for more help. I just want people to understand that I'm trying to make a point for average users like myself.

podunk,

I understand your point exactly. Thanks for sharing your feelings about the .M4A file extension issue. Apple was the first major company to introduce portable players (iPods) that encoded and played files using the MPEG 4 Audio standard (using AAC LC files). They took a bold move in supporting a fairly new standard and making it commonplace to many "average users" like you call yourself. Being the first major mass market MPEG 4 Audio hardware vendor, they set the "standard" by their sheer volume of units distributed of iPod and iTunes.

Since that time of Apple releasing iTunes/iPods, many software programs have appeared with MPEG 4 Audio playback/encoding support. Unfortunately many of them chose to adopt the .MP4 file extension naming format, instead of following what Apple used (.M4A). This has resulted in the dual use of file extension situation we are facing now, and many apps only saving/playing .mp4 files.

As Apple continues to push the use iTunes and iPods (like in the 100 million free songs Pepsi promotion), and now that HP is going to be distributing a copy of iTunes with every consumer PC they sell, iTunes will grow even more popular as will the the use by users of .M4A files. Software makers need to embrace the .M4A file extension and Apple iTunes file/tagging compatibility in my opinion, or else they will have many disgruntled/frustrated users. So software programs supporting BOTH file extensions seems the only logical way to go to solve this already fragmented file extension issue.

I agree with your below statement podunk. It's time to promote MPEG 4 Audio to the world and not quibble over which file extension to use. The fact of the matter is that we have 2 file extensions for the same thing now, so we must live with it.

Its too late for philosophy. Lets deal with reality.

I would assume (and please correct me if I am wrong) that software developers could tell the difference of what kind of audio format is included in a .M4A file. Since MPEG 4 Audio is an international standard, all programs should be able to playback any file encoded with that standard.

Right now we have had extensions to the standard recently (HE AAC and the upcoming lossless ALS audio standard) which aren't supported by all players/apps yet. But having a separate .M4A file extension to denote audio is wise as it will prevent players from thinking it has video/other content in it.

It is up to the players to be compliant with the MPEG 4 Audio standard. If a file doesn't play properly (and that file is MPEG 4 standards compatible) it is the fault of the player which is not 100% standards compatible.

Now I understand the case for not supporting MAIN and LTP parts of the standard, as not all players/encoders support them. That is why AAC LC is the lowest common denominator and is support by most MPEG 4 Audio players and encoders.

But as far as the newer extensions like HE AAC and the soon to be approved ALS standard, future players/encoders should support both of these extensions IMO. These files should use the same .M4A extension, as they are all MPEG 4 Audio. It is up to the MPEG 4 Audio player software to properly recognize them and play them back.

I'm afraid it isn't that simple, since there are many different types of encoded audio and/or video data which can be carried by an MP4 file, but indeed an application should be able to recognize the type of data. Unfortunately there are so many possibilities that it's simply unpossible for a single application to support them all, even in the case of MPEG-4 audio, which is more than AAC.

For example, an MP4 file can contain various data streams, some of them may be audio. If a particular stream is MPEG-4 audio (could be MPEG-1/2 audio as well), this is indicated by a specific ObjectTypeIndication value (= 0x40), but then it could still be AAC Main, ACC LC, AAC scalable, TwinVQ, CELP, HVXC, ..., which is indicated by another AudioObjectType value.

A conclusion like "an MPEG-4 player has to playback any kind of MPEG-4 material" is therefore not applicable, although it might be desirable...

That's absurd. QuickTime is standards compliant, and still it doesn't support even AAC profiles other than LC, let alone other audio formats part of the MPEG4 codec portfolio.

According to your sentence, a player can only claim MPEG4 compliancy if it supports Visual (Simple (which includes SP and ASP), SC, Core, Main, N-Bit, H264, VRML, JPEG2000, etc), Audio (AAC - all countless profiles: LC, MAIN, LTP, LD, SSR, +HE, +PNS, +PS, +ER... - , BSAC, HXVC, TwinVQ, CELP, Structured Audio, Lossless...) and Systems (MP4 container, BIFS, IPMP (aka DRM), MPEG-J, ESM...)

Obviously, a player doesn't need to support all that to claim compatibility. MPEG would be shooting their own feet if they made such crazy requirement.

rjamorim,

My statement was referring to AAC LC and HE AAC only. Note my caveat from the above post:

Now I understand the case for not supporting MAIN and LTP parts of the standard, as not all players/encoders support them. That is why AAC LC is the lowest common denominator and is support by most MPEG 4 Audio players and encoders

So in case I wasn't exactly clear, let me restate what I meant:

An MPEG 4 Audio player shold support AAC LC and HE AAC, including TNS, MS and PNS. Plus in the future it should hopefully support the lossless ALS standard once it is approved by MPEG.

I realize that Main, LTP, etc. support is *not required* in a player. Sorry if I didn't make myself crystal clear of what I meant. Every player should also support HE AAC as that is now part of the standard (an extension to MPEG 4 Audio).

This statement was precipitated by the frustration of WinAmp 5.02's lack on PNS support (it crashes) while all other players seem to handle PNS encoded files OK (or ignore the PNS part). Basically what I'm saying is that you can't call an MPEG 2 player with support for playing .mp4 and .m4a files a true mp4/m4a player. It won't support things like PNS which only appear in the MPEG 4 Audio spec.

Also I believe thet HE AAC support is a *must have* in this day and age, as more people/users start encoding in it (sparked by the popularity of the Nero encoder).

Not even LC, or HE for that matter, are required.



Yes, but that's not required. And you can be compliant without supporting HE AAC.

The KISS DVD player is MPEG4 compliant, and doesn't even support MPEG4 audio or container.

Well I agree with you. Even supporting/using the .MP4 file extension is not required, is it? Apple chose to use .M4A instead and they aren't violating the MPEG 4 Audio standard either.

I think what frustrates most end users about MPEG 4 Audio (as an example of this frustration see podunk's posts above in this thread) is that they expect MPEG 4 Audio to "just work". They are used to MP3 files playing in just about *any* MP3 player or device, and are confused and get frustrated that MP4/M4A audio isn't as "player friendly", especially since it has been touted by many big players in the industry as the 'MP3 replacement'.

So here we are with this 'sticky wicket' with two popular file extensions and one audio file container format for MPEG 4 audio. Somehow it must be possible for all players and encoder to play back/encode to EITHER file extension. That is not asking too much for compatibility and user's ease sake, is it? Also I feel we are sort of like back in the infancy days of MP3 audio a bit. All players and encoders should be "user friendly" in my opinion. A M4A/MP4 file that has AAC LC content should play back in *any* mp4/m4a player, since this is what is most popular.

The addition of HE AAC support to players/encoders should become universal also for the benefit of the many users out there. We all know the quality improvements that HE AAC has to offer for low bitrate encoding. But with a limited "AAC LC only" player the user's experience will be less than enjoyable when playing back HE AAC files.

I didn't think that asking for all players and encoders to support both m4a/mp4 file extensions and AAC LC and hopefully soon (HE AAC) was too much to ask. Maybe I'm wrong.

I'm not up on all the tools available, but it's my understanding that an MPEG 4 container can hold a lot of different formats. In fact, you could stuff MPEG 1 Layer 3 audio into an MPEG 4 container and it'd be standards compliant, correct?

Just out of curiousity, how would one go about doing this? I'm pretty sure iTunes/iPod won't play it, but I'd like to give it a shot anyway.

This issue is currently worked out at MPEG - it's called MP3onMP4. Since it's not finally standardized yet, there is of course no player that supports it.

Bullshit, foobar2000 plays MPEG-1 Layer3 files in a MP4 container just fine.

Solaris

MPEG4ip played MP3 inside MP4 much before Foobar.

MP3 has always been part of the MPEG4 codec portfolio, and lately they have been working on better integrating it with the MP4 container.

I'm sorry, obviously I was wrong, but I thought thhat wouldn't be standard compliant yet. Btw, a reply without the "bullshit" would have been much nicer...

Indeed...

i see that people are evenly split on this. i don't know enough to care either way, but i was wondering about one thing. for future proofing (well, at least as future proof as technology can be) would it be wiser to rip all my cds as mp4 or m4a? where do you guys think this naming debate will end up?

thanks!

norky

Some people prefer .mp4, others like myself prefer .m4a. It is really a personal choice. After all, they are the same MPEG 4 container file format, and any incompatiblity can be resolved via renaming them.

The software developers have recently added the ability to their programs to save/encode using either extensions (user selectable). Most players will play back either extension. The poll results are about evenly split and with Apple pushing M4A and partnering with HP to promote Quicktime/iPods/iTunes, I doubt either M4A or MP4 will stop being used. We are stuck with both and we have to make the best of it. I just think M4A is more descriptive as to what the content is (audio only), and isn't that after all the purpose of a file extension anyway (to denote the content of the file it is attached to)?

Sorry!
I just became a little upset, because your statement was totally wrong. You simply had not checked your sources well enough.

Solaris

Windows will still open Winamp and Winamp doesn't care.



Looks like you've never used BeOS / Zeta. You should try it.