Skip to main content ↑ ↓

Notice

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

Durability of AAC

Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable. Has AAC another way to gain a high durability like MP3? If not, why AAC misses this super feature while MP3 has it? And, does AAC have a file header that is needed to play the file (MP3 doesn't have a such thing and that's a good thing because the file stays playable even if the beginning of it goes)?

Re: Durability of AAC

Reply #1 –
MP3 is just a raw stream, no container, so a decoder can skip corrupted parts and keep looking for valid frames further into the file.  AAC is usually in MP4, which is a complex container.  If you screw up the headers it may not decode at all, although maybe you could write a decoder that is able to recover similar to MP3.  Usually though this is not a major concern at the file level and if you want redundancy or resilience you'd implement that at the file system level with hashes or backups. 

Re: Durability of AAC

Reply #2 –
Quote from: saratoga on
MP3 is just a raw stream, no container, so a decoder can skip corrupted parts and keep looking for valid frames further into the file.  AAC is usually in MP4, which is a complex container.  If you screw up the headers it may not decode at all, although maybe you could write a decoder that is able to recover similar to MP3.  Usually though this is not a major concern at the file level and if you want redundancy or resilience you'd implement that at the file system level with hashes or backups. 

So, MP4 and M4A containers have a file header, right? This is a huge downside compared to MP3. The durability of a file is very important for me, because maybe someone uses this codec in a CD or DVD which can be damaged, or maybe someone streams this codec over a radio connection or something like this. I think every codec container should have frame headers instead of file headers to provide all of the information.

Re: Durability of AAC

Reply #3 –
MP3 may be a good choice for you if that is your concern. 

Re: Durability of AAC

Reply #4 –
Just because there is a container, it doesn't mean that there are no frame headers.

But for a multimedia containers there will be more data around in there (even if it doesn't have video, there will be "room for it", right?) - so a recovery utility for a destroyed audio stream in a destroyed container file might be complicated.

Re: Durability of AAC

Reply #5 –
Quote from: Klymins on
Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable. Has AAC another way to gain a high durability like MP3? If not, why AAC misses this super feature while MP3 has it? And, does AAC have a file header that is needed to play the file (MP3 doesn't have a such thing and that's a good thing because the file stays playable even if the beginning of it goes)?
If you just used a .aac file, it wouldn't be in a container.  .m4a implies an AAC stream in an MP4 container.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Durability of AAC

Reply #6 –
Quote from: Klymins on
because maybe someone uses this codec in a CD or DVD which can be damaged, or maybe someone streams this codec over a radio connection

Unless you plan on encapsulating a raw AAC stream into mode 0 audio CD format (i.e. DTS CD), this isn't really a concern and what are you going to play this on if you do?  You could use a mode 2 data CD-ROM format which was designed for multimedia applications that removes the extra error correction to get larger sector sizes but I wouldn't recommended it for data robustness purposes, which can be a valid concern.  Your average mode 1 CD-ROM format will have extra error correction present.  So the most logically format is a CD-ROM format (a.k.a data CD).  There is also the mode 2 form 2 which is a lot like mode 1 and then there is mode 2 form 1 that is a lot like mode 2 (confusing, huh?).  CDs can get quite complicated.  A mode 0 CD (i.e. audio CD) is an indexed uncompressed PCM stream format with it's own sub channels for containing extra bits of data.  Audio CDs have error correction interleaved and data CDs have extra error detection and error correction present to further improve robustness against errors for computer applications.

On the DVD side neither DVD Audio or DVD Video allow raw AAC streams.  DVD video can allow for MP2 streams to be present.  So this leaves you with a DVD-ROM format which is more like a mode 1 CD-ROM.  DVDs are usually a bit simpler than CDs as everything is arranged into specific files and folders that players will look for rather than a bunch of different modes.

It is more likely whether you're using a mode 1 CD-ROM or DVD-ROM that your drive could get stuck if it encounters a bad sector rather than you getting back a corrupted or damaged file.  Meaning playback could simply just stop as your drive struggles to re-read the bad sector but is unable to recover any data from it.  You are likely to get an incomplete file if you were copying them off the disc that stops at the point where the drive couldn't read the bad sector (i.e. like an incomplete or cancelled download over the internet) if the operating system or application doesn't delete the incomplete file after hitting cancel or skip.

As for radio, it's important to keep in mind robustness is usually built-in to radio and television broadcasting standards to handle weak or bad reception conditions without the receiving equipment getting screwed up in the process, such as skipping past bad or unrecoverable parts of a stream being received or displaying an error message that no signal can be received.  Codecs and container formats that are designed for this are the ones chosen in broadcasting applications.

DVD players usually try to skip past bad sectors unless the disc is so incredibly damaged that the player must abort or stop playback which is why a scratched DVD has issues with missing or corrupted video frames or missing audio.  If the player acted like the drive in your computer does trying to read a bad sector, well you have a very crappy format that stops working completely instead.  The codecs and container formats chosen in the DVD standard are ones designed to handle missing pieces of data.

Re: Durability of AAC

Reply #7 –
Quote from: fooball on
Quote from: Klymins on
Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable. Has AAC another way to gain a high durability like MP3? If not, why AAC misses this super feature while MP3 has it? And, does AAC have a file header that is needed to play the file (MP3 doesn't have a such thing and that's a good thing because the file stays playable even if the beginning of it goes)?
If you just used a .aac file, it wouldn't be in a container.  .m4a implies an AAC stream in an MP4 container.

I used a .m4a file.

Quote from: Chibisteven on
Quote from: Klymins on
because maybe someone uses this codec in a CD or DVD which can be damaged, or maybe someone streams this codec over a radio connection

Unless you plan on encapsulating a raw AAC stream into mode 0 audio CD format (i.e. DTS CD), this isn't really a concern and what are you going to play this on if you do?  You could use a mode 2 data CD-ROM format which was designed for multimedia applications that removes the extra error correction to get larger sector sizes but I wouldn't recommended it for data robustness purposes, which can be a valid concern.  Your average mode 1 CD-ROM format will have extra error correction present.  So the most logically format is a CD-ROM format (a.k.a data CD).  There is also the mode 2 form 2 which is a lot like mode 1 and then there is mode 2 form 1 that is a lot like mode 2 (confusing, huh?).  CDs can get quite complicated.  A mode 0 CD (i.e. audio CD) is an indexed uncompressed PCM stream format with it's own sub channels for containing extra bits of data.  Audio CDs have error correction interleaved and data CDs have extra error detection and error correction present to further improve robustness against errors for computer applications.

On the DVD side neither DVD Audio or DVD Video allow raw AAC streams.  DVD video can allow for MP2 streams to be present.  So this leaves you with a DVD-ROM format which is more like a mode 1 CD-ROM.  DVDs are usually a bit simpler than CDs as everything is arranged into specific files and folders that players will look for rather than a bunch of different modes.

It is more likely whether you're using a mode 1 CD-ROM or DVD-ROM that your drive could get stuck if it encounters a bad sector rather than you getting back a corrupted or damaged file.  Meaning playback could simply just stop as your drive struggles to re-read the bad sector but is unable to recover any data from it.  You are likely to get an incomplete file if you were copying them off the disc that stops at the point where the drive couldn't read the bad sector (i.e. like an incomplete or cancelled download over the internet) if the operating system or application doesn't delete the incomplete file after hitting cancel or skip.

As for radio, it's important to keep in mind robustness is usually built-in to radio and television broadcasting standards to handle weak or bad reception conditions without the receiving equipment getting screwed up in the process, such as skipping past bad or unrecoverable parts of a stream being received or displaying an error message that no signal can be received.  Codecs and container formats that are designed for this are the ones chosen in broadcasting applications.

DVD players usually try to skip past bad sectors unless the disc is so incredibly damaged that the player must abort or stop playback which is why a scratched DVD has issues with missing or corrupted video frames or missing audio.  If the player acted like the drive in your computer does trying to read a bad sector, well you have a very crappy format that stops working completely instead.  The codecs and container formats chosen in the DVD standard are ones designed to handle missing pieces of data.

Thanks for information.

Re: Durability of AAC

Reply #8 –
Quote from: Klymins on
I used a .m4a file.
But that is AAC in an MP4 container.  I refer you to comments about containerising a codec in previous posts.  If you want the AAC more robust, use it without the container (ie raw .aac).

Quote from: Chibisteven on
container formats that are designed for this are the ones chosen in broadcasting applications
Indeed – Transport Stream (TS).  AAC audio is used in TS for HD DTV broadcasting in the UK.  TS is designed to recover from dropped/corrupt frames.

@Klymins you seem overly concerned about a theoretical situation which could occur, but which would be the result of inappropriate choices in the first place.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Durability of AAC

Reply #9 –
Quote from: fooball on
Quote from: Klymins on
I used a .m4a file.
But that is AAC in an MP4 container.  I refer you to comments about containerising a codec in previous posts.  If you want the AAC more robust, use it without the container (ie raw .aac).

Quote from: Chibisteven on
container formats that are designed for this are the ones chosen in broadcasting applications
Indeed – Transport Stream (TS).  AAC audio is used in TS for HD DTV broadcasting in the UK.  TS is designed to recover from dropped/corrupt frames.

@Klymins you seem overly concerned about a theoretical situation which could occur, but which would be the result of inappropriate choices in the first place.

Thanks.

Re: Durability of AAC

Reply #10 –
Quote from: Klymins on
Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable.
By the way, if you want to test closer to apples-to-apples, you can encapsulate an MP3 in an MP4 and try the same thing. And extract AAC to .aac.
You can try MKV container too.

ffmpeg -i mp3audio.mp3 -acodec copy -vn -sn mp3audio.mp4
ffmpeg -i mp3audio.mp3 -acodec copy -vn -sn mp3audio.mka

ffmpeg -i aacaudio.m4a -acodec copy -vn -sn aacaudio.mka
ffmpeg -i aacaudio.m4a -acodec copy -vn -sn aacaudio.aac


Then open in a hex editor (say https://mh-nexus.de/en/hxd/ ). 
Test to corrupt audio by overwriting same audio in all three versions:
The three files containing AAC: find a suitable string that doesn't contain any FF or have one "nearby" (because then you might be in headers!), search, verify that it only occurs once in each AAC file, replace it with something of the same length.
Do the same for the three MP3 files. You cannot expect the same string, of course. Try to get it around the same place in the files.
Test file integrity. If it looks OK, it might be you are in "unprotected" land where it cannot tell - revert to unaltered file, find a different string and try again.

You can also corrupt by removing a byte. Then in the replacement text, do one byte shorter (a double hex, say "BD"). Or two bytes ...  I have no idea whether there is something that is supposed to be aligned to the double-byte. 

Corrupting headers ... oh, that's a job to learn how to find, what are valid but nonsense, etc.

Re: Durability of AAC

Reply #11 –
Unfortunately, a pretty frequent situation may be (at least what some of my friends have encountered) when you're trying to copy files from a hard drive onto a USB flash drive, it crashes in the middle of the operation, and when you call the copy command next time, it tries to resume from where it left off. Sadly, in situations like these, you may experience things like several bytes getting cut out somewhere in the middle of the file. This is nicely audible on uncompressed PCM files that have more than 8 bits of resolution because then from the damaged spot onwards, the MSB is no longer at the expected position of the MSB.
For compressed files, the contents can sometimes be damaged even by changing the value of one byte in the middle, even though the byte is neither added nor cut out. I remember my former schoolmate complaining about several of his Vorbis encodes being damaged somewhere in the middle of the files, even though he was just keeping them on his SSD drive for several years (believe it or not, he was not intentionally meaning to change the data).
And along the same lines, I recently tested Opusdec in terms of self-synchronization after repeating something like 128 bytes in the middle of an Opus file and I was happy to find that its degree of self-synchronization was pretty good.

Re: Durability of AAC

Reply #12 –
Use a copy utility with verification!

As for error handling, I did a brief test at https://hydrogenaud.io/index.php/topic,122094.msg1007964.html#msg1007964 - a few lossies too, even if at first I tried to test lossless formats.

Things that have happened since:
* The reference FLAC decoder will now mute but keep the right duration
* Monkey's has gotten fast-verification in the CLI too.

Re: Durability of AAC

Reply #13 –
Quote from: Klymins on
Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable.

With "notepad" on what - Windows??

I just noticed the ramifications of this... editing binary files with a text editor won't be just a "little" edit, it will corrupt the whole file (anywhere a line feed character gets detected), and possibly ignore nulls and/or truncate at an end-of-file character.

If you must do this, be sure to use a binary (ie hex) editor.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Durability of AAC

Reply #16 –
I find Notepad++ painfully slow on such big files - maybe it is the autosave, which I don't want to switch off - so even if it does have a hex editor plugin, I don't use it.
(I'm using HxD, as linked to above.)

Re: Durability of AAC

Reply #17 –
Quote from: a.ok.in on
Could Notepad++ be another valid option?
Only if Notepad++ has a binary option, and I do not recall that it has (unable to check at the moment).

The point is that in ASCII (ie text), some code points are allocated to control, and even if you get LFs and CRs to be retained without modification (Notepad++ is better than Notepad in this respect, because it can be set to write either DOS or UNIX line endings), if a program is expecting ASCII input it might well ignore some or all of the non-text codes it reads, and interpret others as it should.  One such troublesome code is EOF.

If I were at home right now, I would attach a file containing every binary code at least twice, for interested parties to test in their favourite editor.  All you would have to do is read the file, then save it with a new name, and check the file sizes.  Notepad would definitely fail this test.

The bottom line is: if dealing with non-ASCII data, it's not worth the risk "playing" with it in any tool other than a dedicated hex editor – just get one.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Durability of AAC

Reply #18 –
Quote from: fooball on
Quote from: Klymins on
Hello. I've tried to corrupt an AAC (.m4a) file and it was very easy, just a little edit with notepad rendered it unplayable.

With "notepad" on what - Windows??

I just noticed the ramifications of this... editing binary files with a text editor won't be just a "little" edit, it will corrupt the whole file (anywhere a line feed character gets detected), and possibly ignore nulls and/or truncate at an end-of-file character.

If you must do this, be sure to use a binary (ie hex) editor.

Yes, and that's the point. MP3 is capable of handling this, but AAC is not (I've also tried with .aac.), and I want a codec that is capable of what the notepad does. So, I deliberately use the notepad and not a hex editor.

Re: Durability of AAC

Reply #19 –
physical disk corruption doesn't really cause data to be offset (shifted);
intentional mangling with notepad doesn't sound like a realistic / practical scenario.
Sounds like X/Y problem.

Are you interested in this because you have a particular practical problem in mind? if so what is it?

btw: if a file copy could have been failed, in any case it's wise to compare checksums or something like that, when you still have the original at hand.
because, no matter the error concealment abilities, you'd prefer the undamaged file.
a fan of AutoEq + Meier Crossfeed

Re: Durability of AAC

Reply #20 –
Quote from: Klymins on
MP3 is capable of handling this, but AAC is not (I've also tried with .aac.)
And without a hex editor, do you know whether you corrupted "similar" parts of the file so that you are comparing apples-to-apples?
I might have gotten it wrong in https://hydrogenaud.io/index.php/topic,122094.msg1007969.html#msg1007969 , since foobar2000 handled a presumably more severe corruption of the AAC file.

Whether outputting wrong and concealing the error is "handling this" is ... certainly up to opinion.

Also, beware that you won't get a raw AAC file by merely renaming ".m4a" to ".aac".

Re: Durability of AAC

Reply #21 –
Quote from: Klymins on
I want a codec that is capable of what the notepad does. So, I deliberately use the notepad and not a hex editor.
You must be insane.  What an utter waste of time.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Durability of AAC

Reply #22 –
Quote from: Porcus on
Quote from: Klymins on
MP3 is capable of handling this, but AAC is not (I've also tried with .aac.)
Also, beware that you won't get a raw AAC file by merely renaming ".m4a" to ".aac".

I know.

Quote from: fooball on
Quote from: Klymins on
I want a codec that is capable of what the notepad does. So, I deliberately use the notepad and not a hex editor.
You must be insane.  What an utter waste of time.

MP3 is capable of handling this (the sound gets distorted but it's still listenable), so I'm not insane.

Re: Durability of AAC

Reply #23 –
Notepad is a text editor.
A text editor can delete all the audio. A text editor can destroy the frame headers.

There is a point whether it is possible to deal with a single byte altered randomly by
* detecting it and warning the user
* muting the corrupted part as not to spit loud static down the playback chain
* resync nearly immediately after the corruption, and playing the rest
... and in practice it is surely a point whether common players can do that.

But that is not a matter of "but I want to use specifically Notepad to mutilate my files, and nothing else!"

 

Re: Durability of AAC

Reply #24 –
Quote from: Klymins on
MP3 is capable of handling this (the sound gets distorted but it's still listenable), so I'm not insane.
If you are saying there is a use-case where a media file must be intelligible/listenable after an inept user has inadvisably forced Notepad to load a non-.txt file and then "accidentally" gone on to save the resulting garbage...  IIRC you would have had to rename the file to .txt, edit it, then rename it back to .m4a (or whatever).  That hardly seems accidental.

Provide such a use-case and I'll concur you're not insane.

Otherwise you're just inventing scenarios which can only ever happen by deliberate misuse, and if you're looking to mitigate all possible misuse you're on a Sisyphean quest.  It would be far better to protect the original file from being corrupted in the first place.

If MP3 is robust enough to survive your deliberate mangling, that's great... but I see no reason to expect other codecs to behave the same way.  If MP3 works for you, stick with that.
It's your privilege to disagree, but that doesn't make you right and me wrong.