Same MP3 files differ in one 16-bit value - audio

I have this mistery that happened to me recently with my MP3 files. I had a few MP3s that should be identical, but as I have discovered, those files doesn't seem to be identical by their content. I have tried many tools for comparison of the files, but all of them gave me the same result - those files seemed to be different.
When I looked at those files with MediaInfo, it appeared as if those files were the same. They had the same tags, same content (when comparing in Audacity) and overall I haven't noticed anything weird about it.
The last thing that came to my mind is to put these files to the diff tool. I have utilized the command
colordiff --side-by-side --suppress-common-lines -y <(xxd file1.mp3) <(xxd file2.mp3)
and got an interesting result. The output of the diff was following:
00000000: 0b08 0000 0000 3402 0002 fffa 52c0 268d ......4... | 00000000: 0b08 0000 0000 4403 0002 fffa 52c0 268d ......D...
Weird... a single 16-bit value difference. This is the only difference when comparing two files which should be identical. When comparing the whole file, the output got really messy, so I'm not sure from where this particular line came, but I guess it belongs to the file header, because I don't think the content of the MP3 would get modified, rather I do suspect the metadata.
Other than this info I'm not really sure what can cause this, but I thought it is wort a shot to share this issue with StackOVerflow to find out more. Thank you for all your replies, I will try to provide any further details if needed.

Related

Comparing and isolating the difference in 2 mp3 files

I have an archive of old radio shows, and for each show I have 2 different mp3 files.
The first is a podcast version of the show, released by the station. This is a truncated version of the show with a lot of content cut out.
The second is a recording of the full show, as it was aired.
I would like to compare the two mp3 files for each show and isolate the bits from the full version that DON'T appear in the podcast version.
Does anyone know of any software capable of doing this?
I read that an abx comparator might be what I need, but I've watched a few video tutorials for the foobar abx comparator and I'm pretty sure that's not what I'm looking for.
Thanks

.wac to .wav conversion

I've been asked to sample some data in a .wac file type. I'm not familiar with this standard and there is very little on the internet with regards to this format. I got given the .wav file but I don't think it was converted correctly, in that there was a none existent of the RIFF header so no .wav reader was able to read it.
Could anyone therefore shed some light into how I could possibly convert the .wac file into a .wav file? Doing some research, I cannot seem to find a converter tool on the internet, and, MatLab does not have a module for reading in .wac data.
NOTE: I've put the tag "game-engine" because according to this website: Here it is used in the infinity game engine.
I've come up with the following solution, however, massive thanks to #jpaari for his input.
Basically, I used sox:
sox -r 44100 -e unsigned -b 8 -c 1 input.raw output.wav
I was able to re-name the file to .raw and this worked. I'm going to update the Sample Rate to what #Aybe posted.
Try this http://www.shsforums.net/topic/39117-ps-gui-v304/
I think Audacity can do it aswell. Also the "unity3d" tag is not quite right.

Hashing raw audio data

I'm looking for a solution to this task: I want to open any audio file (MP3,FLAC,WAV), then proceed it to the extracted form and hash this data. The thing is: I don't know how to get this extracted audio data. DirectX could do the job, right? And also, I suppose if I have fo example two MP3 files, both 320kbps and only ID3 tags differ and there's a garbage inside on of the files mixed with audio data (MP3 format allows garbage to be inside) and I extract both files, I should get the exactly same audio data, right? I'd only differ if one file is 128 and the other 320, for example. Okay so, the question is, is there a way to use DirectX to get this extracted audio data? I imagine it'd be some function returning byte array or something. Also, it would be handy to just extract whole file without playback. I want to process hundreds of files so 3-10min/s each (if files have to be played at natural speed for decoding) is way worse that one second for each file (only extracting)
I hope my question is understandable.
Thanks a lot for answers,
Aaron
Use http://sox.sourceforge.net/ (multiplatform). It's faster than realtime as you'd like, and it's designed for batch mode much more than DirectX. For example, sox -r 48k -b 16 -L -c 1 in.mp3 out.raw. Loop that over your hundreds of files using whatever scripting language you like (bash, python, .bat, ...).

basic wav data chunk

I have a question about the basic wav file data chunk.
I know that each 2 bytes in the data chunk section represent mono sound and left and right channel is alternately stored, but I still have no idea how to understand the 2 byte value.
Is it high and low?
value 0000 => lowest?
value FFFF => highest?
value 8FFF => no sound?
If so, when I want to reduce volume 50%, is all I have to do just classfy low and high
and divive by 2?
WAV files can contain samples at different bit depths and encodings, but one of the most commonly used is 16 bit PCM. With 16 bit PCM data in a WAV file, each two bytes should be interpreted as a short (i.e. a signed, two-byte number). In WAV files, the samples are always "little-endian". If you tag your question with a language, someone might be able to provide some simple sample code. In C/C++, you would cast your array of data read from the file into a (short *), allowing you to easily access each sample.
To answer the second part of your question, yes you can reduce the volume by halving the value of each sample.
Your understanding seems fine. The only thing I can think to say is one byte will be a most significant byte, and one will be least significant. Other than that, you seem spot on.
And your question is fine (In my opinion anyway!) Although more useful answers might be gotten if you were to ask a specific programming question, but I can see how that might not be possible.

What is the best way to merge mp3 files? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've got many, many mp3 files that I would like to merge into a single file. I've used the command line method
copy /b 1.mp3+2.mp3 3.mp3
but it's a pain when there's a lot of them and their namings are inconsistent. The time never seems to come out right either.
David's answer is correct that just concatenating the files will leave ID3 tags scattered inside (although this doesn't normally affect playback, so you can do "copy /b" or on UNIX "cat a.mp3 b.mp3 > combined.mp3" in a pinch).
However, mp3wrap isn't exactly the right tool to just combine multiple MP3s into one "clean" file. Rather than using ID3, it actually inserts its own custom data format in amongst the MP3 frames (the "wrap" part), which causes issues with playback, particularly on iTunes and iPods. Although the file will play back fine if you just let them run from start to finish (because players will skip these is arbitrary non-MPEG bytes) the file duration and bitrate will be reported incorrectly, which breaks seeking. Also, mp3wrap will wipe out all your ID3 metadata, including cover art, and fail to update the VBR header with the correct file length.
mp3cat on its own will produce a good concatenated data file (so, better than mp3wrap), but it also strips ID3 tags and fails to update the VBR header with the correct length of the joined file.
Here's a good explanation of these issues and method (two actually) to combine MP3 files and produce a "clean" final result with original metadata intact -- it's command-line so works on Mac/Linux/BSD etc. It uses:
mp3cat to combine the MPEG data frames only into a continuous file, then
id3cp to copy all metadata over to the combined file, and finally
VBRFix to update the VBR header.
For a Windows GUI tool, take a look at Merge MP3 -- it takes care of everything. (VBRFix also comes in GUI form, but it doesn't do the joining.)
As Thomas Owens pointed out, simply concatenating the files will leave multiple ID3 headers scattered throughout the resulting concatenated file - so the time/bitrate info will be wildly wrong.
You're going to need to use a tool which can combine the audio data for you.
mp3wrap would be ideal for this - it's designed to join together MP3 files, without needing to decode + re-encode the data (which would result in a loss of audio quality) and will also deal with the ID3 tags intelligently.
The resulting file can also be split back into its component parts using the mp3splt tool - mp3wrap adds information to the IDv3 comment to allow this.
Use ffmpeg or a similar tool to convert all of your MP3s into a consistent format, e.g.
ffmpeg -i originalA.mp3 -f mp3 -ab 128kb -ar 44100 -ac 2 intermediateA.mp3
ffmpeg -i originalB.mp3 -f mp3 -ab 128kb -ar 44100 -ac 2 intermediateB.mp3
Then, at runtime, concat your files together:
cat intermediateA.mp3 intermediateB.mp3 > output.mp3
Finally, run them through the tool MP3Val to fix any stream errors without forcing a full re-encode:
mp3val output.mp3 -f -nb
The time problem has to do with the ID3 headers of the MP3 files, which is something your method isn't taking into account as the entire file is copied.
Do you have a language of choice that you want to use or doesn't it matter? That will affect what libraries are available that support the operations you want.
MP3 files have headers you need to respect.
You could ether use a library like Open Source Audio Library Project and write a tool around it.
Or you can use a tool that understands mp3 files like Audacity.
What I really wanted was a GUI to reorder them and output them as one file
Playlist Producer does exactly that, decoding and reencoding them into a combined MP3. It's designed for creating mix tapes or simple podcasts, but you might find it useful.
(Disclosure: I wrote the software, and I profit if you buy the Pro Edition. The Lite edition is a free version with a few limitations).
As David says, mp3wrap is the way to go. However, I found that it didn't fix the audio length header, so iTunes refused to play the whole file even though all the data was there. (I merged three 7-minute files, but it only saw up to the first 7 minutes.)
I dug up this blog post, which explains how to fix this and also how to copy the ID3 tags over from the original files (on its own, mp3wrap deletes your ID3 tags). Or to just copy the tags (using id3cp from id3lib), do:
id3cp original.mp3 new.mp3
I would use Winamp to do this. Create a playlist of files you want to merge into one, select Disk Writer output plugin, choose filename and you're done. The file you will get will be correct MP3 file and you can set bitrate etc.
I'd not heard of mp3wrap before. Looks great. I'm guessing someone's made it into a gui as well somewhere. But, just to respond to the original post, I've written a gui that does the COPY /b method. So, under the covers, nothing new under the sun, but the program is all about making the process less painful if you have a lot of files to merge...AND you don't want to re-encode AND each set of files to merge are the same bitrate. If you have that (and you're on Windows), check out Mp3Merge at: http://www.leighweb.com/david/mp3merge and see if that's what you're looking for.
If you want something free with a simple user interface that makes a completely clean mp3 I recommend MP3 Joiner.
Features:
Strips ID3 data (both ID3v1 and ID3v2.x) and doesn't add it's own (unlike mp3wrap)
Lossless joining (doesn't decode and re-encode the .mp3s). No codecs required.
Simple UI (see below)
Low memory usage (uses streams)
Very fast (compared to mp3wrap)
I wrote it :) - so you can request features and I'll add them.
Links:
MP3 Joiner website: Here
Latest installer: Here
Personally I would use something like mplayer with the audio pass though option eg -oac copy
Instead of using the command line to do
copy /b 1.mp3+2.mp3 3.mp3
you could instead use "The Rename" to rename all the MP3 fragments into a series of names that are in order based on some kind of counter. Then you could just use the same command line format but change it a little to:
copy /b *.mp3 output_name.mp3
That is assuming you ripped all of these fragment MP3's at the same time and they have the same audio settings. Worked great for me when I was converting an Audio book I had in .aa to a single .mp3. I had to burn all the .aa files to 9 CD's then rip all 9 CD's and then I was left with about 90 mp3's. Really a pain in the a55.

Resources