I have to play various mp3 files on a given software without showing any information that could lead to the recognition of the played track (some kind of quiz). For that, I want to change the displayed track length to an arbitrary value. I can easily change up standard ID3 tags like "name", "artist" and so on. But changing the displayed track length seems to be more tricky, though...
Edit (after Vikram's response):
So far, I was able to manipulate the displayed track length by modifying the 'xing' header in a vbr encoded mp3 file. More precisely, I changed the bytes in the 'number of frames' section with a hex editor which lead to an mp3 that showed a modified track length according to:
Track length = Number of Frames * Samples Per Frame / Sampling Rate
with the file still being correctly played. This approach seems to work for winamp, vlc player and windows in general. Unfortunately, it does not seem to work for the proprietary software I have to use. When using that software, somehow the original track duration is still identified because a different calculation method is applied.
Any other ideas on how the track duration could be calculated resp. fooled into displaying an arbitrary value?
Thanks!
YES and NO.
Most of the .mp3 files have this extra info besides ID3 in XING header, which contains duration of the file.
You can modify this header to put wrong info.
Or you can simply remove this XING header!
There are two types of .mp3 files: CBR and VBR.
CBR is most common. So, using bitrate info, players still can estimate length of the audio for CBR.
For VBR this is not always correct!
So, the audio file you had was most likely an VBR encoded mp3 without XING header.
The track length is calculated by parsing the whole MPEG audio stream, a fairly straight forward process. XING (or similar) headers (correctly: frames) exist as a help like an additional index for seeking in the file, but it is not mandatory; it also only exists because 25 years ago in most cases it would have taken too much performance to fully parse files and keeping relevant data in memory when VBR was "invented". Metadata, where you could define incorrect track lengths (like the TLEN frame thru ID3v2) aren't mandatory either.
So: it's not possible. You rather found software/players that opt for performance without assuring everything they spot. Also no other file/stream format comes to my mind where a track length is mandatory and cannot be calculated by parsing the file.
Related
This question is about extraction of metadata only.
Is it required for exiftool to get a complete file for propperly working?
Scenario:
I want to extract the metadata of a 20 GB video file. Do I need to provide exiftool with the complete file (via stdin), or is it enough to provide it with a certain amount of bytes.
Motivation:
I am programatically (golang) calling exiftool in a streaming context and want to have the extraction as fast as possible. Magic numbers for filetypes work with the first 33 bytes and I am wondering if that is possible with the exiftool metadata as well.
The answer depends upon the file and the location of the metadata within that file.
There are a couple of threads on the subject on the ExifTool forums (link 1, link 2) and Phil Harvey, the author, says that about half the time the in the case of MP4/MOV videos, the metadata is at the end of the file.
Using the -fast option might help. I've done some quick tests using cURL and a large image file (see the second to the last example under Piping Examples) and in that case cURL didn't download the whole image file, just enough to extra the metadata. It might be different with a video file though, as I haven't tested that situation.
Ideally I want a way to uniquely identify files (audio files) where things like the ID3 tag or the file name can change and the hash remains the same.
Is there a better way I don't know of to uniquely identify files? Or would I have to change my record of the file every time an edit was made? Can I hash on other pieces of data or something?
If you only count files wich have EXACTLY the same audio information as "the same" (same bit depth, bitrate, compression, etc.) its pretty easy: you would just hash the "audio" part of the file. im not too familiar with the MPEG audio codec myself though.
reading material:
http://en.wikipedia.org/wiki/MP3
http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm
How do you split an audio file into multiple parts using MATLAB ? Like I have an audio file composed of ten-twenty notes of a Piano, I need to split it into individual notes and store each note in a separate variable . Is it possible to do this with MATLAB ,if so how ? Can anyone please help me on this ?
If you want to do the splitting visually you can try "Simple Audio Editor" available in the file exchange.
http://www.mathworks.com/matlabcentral/fileexchange/19873-simple-audio-editor
I am the author of this program. Let me know if something does not work with that.
You can also try a free audio editor like audacity and export individual pieces to audio files. You can read each piece in MATLAB separately.
If you are looking to achieve this automatically you might need to ask this question in a Signal processing group.
we know movie atom in a MP4 container file stores information that describes a movie's data. I am wondering if a single MP4 file can contain more than one movie atoms (atom type of 'moov')?
anyone knows? Thanks
A valid MP4 file may only contain one single 'moov' box. This is stated in 8.2.1 of the ISO 14496-12 specification:
The metadata for a presentation is stored in the single Movie Box which occurs at the top-level of a file.
Normally this box is close to the beginning or end of the file, though this is not required.
If you are using fragmented MP4 files the role of the 'moov' is mostly played by 'moof' boxes and those typically exist multiple times.
I would like to play some kind of text-to-speech with only numbers. I can record 10 wav files, but how can I combine them programmatically ?
For instance, the user types 1234, and the text-to-speech combines 1.wav with 2.wav, 3.wav and 4.wav to produce 1234.wav that plays "one two three four".
1) create a new destination sample buffer (you will want to know the sizes).
2) read the samples (e.g. using AudioFile and ExtAudioFile APIs) and write them in sequence to the buffer. You may want to add silence between the files.
It will help if your files are all the same bit depth (the destination bit depth - 16 should be fine) and sample rate.
Alternatively, if you have fixed, known, sample rates and bit depths for all files, you could just save them as raw sample data and be done in much less time because you could simply append the data as is without writing all the extra audio file reading programs.
The open source project wavtools provides a good reference for this sort of work, if you're ok with perl. Otherwise there is a similar question with some java examples.
The simplist common .wav (RIFF) file format just has a 44 byte header in front of raw PCM samples. So, for these simple types of .wav files, you could just try reading the files as raw bytes, removing the 44 byte header from all but the first file, and concatening the samples. Or just play the concatenated samples directly using the Audio Queue API.