Hello,
I couldn't find an answer for this, so I doubt there is one: I have 100s of mp3 files, from which I needed to extract data - namely name, and duration. As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this? Or I guess I could get the elements using an other program and save them as .txt files, but it would be much more interesting to do it inside Pd.
System: Pd-Ext, W7.
Best,
jmmmp
Hello,
I couldn't find an answer for this, so I doubt there is one: I have 100s of mp3 files, from which I needed to extract data - namely name, and duration.
Would that be file name, or artist name?
As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this?
On Linux I'd simply run the sox or soxi command from the command line: soxi *.mp3 and save its output to a textfile. Afaik sox is available for Windows as well, perhaps take a look at http://sox.sourceforge.net/SoX
I couldn't find an answer for this, so I doubt there is one: I have 100s of mp3 files, from which I needed to extract data - namely name, and duration.
Would that be file name, or artist name?
yes, file name. although as a general idea it's interesting to get any
field of the metadata.
As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this?
On Linux I'd simply run the sox or soxi command from the command line: soxi *.mp3 and save its output to a textfile. Afaik sox is available for Windows as well, perhaps take a look at http://sox.sourceforge.net/SoX
yes, I imagine there is no other choice with current pd objects. which is
a pity, as mp3 support is far from ideal.
You can run that command with the shell object from extended.. can't you?
On Sat, Apr 4, 2015 at 7:21 PM, João Pais jmmmpais@gmail.com wrote:
I couldn't find an answer for this, so I doubt there is one: I have 100s
of mp3 files, from which I needed to extract data - namely name, and duration.
Would that be file name, or artist name?
yes, file name. although as a general idea it's interesting to get any field of the metadata.
As I can tell, there isn't any object that does this, e.g. like
[ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this?
On Linux I'd simply run the sox or soxi command from the command line: soxi *.mp3 and save its output to a textfile. Afaik sox is available for Windows as well, perhaps take a look at http://sox.sourceforge.net/SoX
yes, I imagine there is no other choice with current pd objects. which is a pity, as mp3 support is far from ideal.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
shell doesn't work in windows. there might be a similar object (although I
didn't find it yet), or I can try any other kind of command.
but it would be nice to do it directly from Pd. I can do it already with
wav files through wavinfo, but it's a bit exagerated to convert several
Gbs of mp3 to wav, when I only need the information (I'm even not going to
play them).
You can run that command with the shell object from extended.. can't you?
On Sat, Apr 4, 2015 at 7:21 PM, João Pais jmmmpais@gmail.com wrote:
I couldn't find an answer for this, so I doubt there is one: I have
100s of mp3 files, from which I needed to extract data - namely name, and duration.Would that be file name, or artist name?
yes, file name. although as a general idea it's interesting to get any
field of the metadata.As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this?
On Linux I'd simply run the sox or soxi command from the command line: soxi *.mp3 and save its output to a textfile. Afaik sox is available for Windows as well, perhaps take a look at http://sox.sourceforge.net/SoX
yes, I imagine there is no other choice with current pd objects. which
is a pity, as mp3 support is far from ideal.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On Sat, Apr 4, 2015 at 2:21 PM, João Pais jmmmpais@gmail.com wrote:
I couldn't find an answer for this, so I doubt there is one: I have 100s
of mp3 files, from which I needed to extract data - namely name, and duration.
Would that be file name, or artist name?
yes, file name. although as a general idea it's interesting to get any field of the metadata.
As I can tell, there isn't any object that does this, e.g. like
[ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this?
On Linux I'd simply run the sox or soxi command from the command line: soxi *.mp3 and save its output to a textfile. Afaik sox is available for Windows as well, perhaps take a look at http://sox.sourceforge.net/SoX
yes, I imagine there is no other choice with current pd objects. which is a pity, as mp3 support is far from ideal.
It seems there is no standard for the metadata in mp3 and several different methods are in use. Some of them are at the end of the file and others at the beginning, so it's not straightforward. Most of the tags give the name but not all of them give the length, and since mp3 is compressed in a non-linear way, there's no way to determine the length except by playing it.
Martin
On Sam, 2015-04-04 at 15:12 -0400, Martin Peach wrote:
Most of the tags give the name but not all of them give the length, and since mp3 is compressed in a non-linear way, there's no way to determine the length except by playing it.
If the file is compressed with a constant bitrate, it's easy to calculate the play duration. Not so easy with variable bitrate, though some programs still seem to do it correctly. mplayer does it wrong, mpv does it correct, for instancce. I don't know how the "intelligent" ones do it.
Roman
It seems there is no standard for the metadata in mp3 and several
different methods are in use. Some of them are at the end of the file
and others at >the beginning, so it's not straightforward. Most of the tags give the name but not all of them give the length, and
since mp3 is compressed in a non-linear way, there's no way to determine
the >length except by playing it.
I never went that far into the insides of mp3 coding. but since any file
player software indicates the duration of an mp3 when you add it to the
playlist, that information must be easy to get from somewhere.
Joao
It seems there is no standard for the metadata in mp3 and several different methods are in use. Some of them are at the end of the file and others at >the beginning, so it's not straightforward. Most of the tags give the name but not all of them give the length, and since mp3 is compressed in a non-linear way, there's no way to determine the >length except by playing it.
I never went that far into the insides of mp3 coding. but since any file player software indicates the duration of an mp3 when you add it to the playlist, that information must be easy to get from somewhere.
soxi myfile.mp3
gives the following info, which I suspect to be from the header rather than from the mp3 metadata itself:
Input File : 'myfile.mp3' Channels : 1 Sample Rate : 44100 Precision : 16-bit Duration : 00:00:05.83 = 256927 samples = 436.951 CDDA sectors File Size : 46.6k Bit Rate : 64.0k Sample Encoding: MPEG audio (layer I, II or III)
Hi, here are precisions about methods used to get length of an mp3 file :
"TLEN" frame, indicating length of the mp3 file in milliseconds
encoder added a Xing header providing the total number of encoded frames, which is enough to get duration once samplerate and mpeg version have been obtained from header of a single mp3 frame. INDEED : no matter the number of channels or bitrate variation, a frame of an MPEG Layer III audio file ALWAYS contains 1152 audio samples per channel (for mpeg1 version, but low quality mpeg2 and 2.5 audio formats have 576 samples per frame), therefore : total duration = number of mp3 frames * 1152 / samplerate
mp3 frames of the file must be found and counted. Like when playing it, each frame header is identified (by a "frame sync" pattern at start of header) then parsed to determine this frame's bitrate needed to calcultate its size, in order to get next frame position, and so on...
file was probably encoded with constant rate (CBR) so it is reasonable to expect that bitrate and frame length will remain unchanged with subsequent frames. In this case, to save time, the number of frames can be extrapolated from total audio data size (file size without metadata headers).
Looking at their source code (links below), previously mentionned utilities appear to proceed in this order to find play duration. But it seems that exiftool, in absence of a Xing header, will always extrapolate, parsing only the first mp3 frame to get bitrate (and assuming that it is constant) but this sole value could be far from actual average bitrate of a VBR encoded file, resulting in a wrong estimation.
By contrast, soxi (or sox --i), has a more appropriate approach for this case (and its verbosity can be maxed out with -V6 option to clearly see how duration is actually measured) : its parses 25 frames to establish bitrate situation before extrapolating when constant... or proceeding to full count of frames otherwise, which is the always the most accurate strategy :
Some dubious MP3s from the interweb may be truncated, with erroneous metadata headers, or occasionnaly with gaps and ancillary data inserted between (possibly invalid) audio frames... then real play duration will correspond to frames actually "validated" and decoded by some mp3 player. For accuracy, it seems like a good idea to always parse all frames, and in that sense, Martin was kind of right when he said "there's no way to determine the length except by playing it" :)
Another command, mp3info (windows binary available), despite the fact it will only decode the old ID3v1 header to get artist/title metadata (most files with ID3v2 headers come with v1 headers at end of file anyway), has nice parameters like -p ("printf"-style custom output format with many options) and -F to force "full scan", meaning count of all valid mp3 frames for duration calculation (see "Speed Considerations" in manpage, with similar explanations : http://manpages.ubuntu.com/manpages/hardy/man1/mp3info.1.html )
references : sox : https://github.com/uklauer/sox/blob/master/src/mp3-util.h exiftool : http://sourceforge.net/p/exiftool/code/ci/master/tree/lib/Image/ExifTool/MPE... Cheers, Nicolas
I've no windows machine actually but it would be worth to try to get a dll of this external:
http://www.matthiaskronlachner.com/?p=302
otherwise a python script or a php script would do it well
Le 04/04/2015 13:23, João Pais a écrit :
Hello,
I couldn't find an answer for this, so I doubt there is one: I have 100s of mp3 files, from which I needed to extract data - namely name, and duration. As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this? Or I guess I could get the elements using an other program and save them as .txt files, but it would be much more interesting to do it inside Pd.
System: Pd-Ext, W7.
Best,
jmmmp
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sam, 2015-04-04 at 13:23 +0200, João Pais wrote:
Hello,
I couldn't find an answer for this, so I doubt there is one: I have 100s of mp3 files, from which I needed to extract data - namely name, and duration. As I can tell, there isn't any object that does this, e.g. like [ext13/wavinfo] (hopefully I'm wrong). Does anyone has an elegant solution for this? Or I guess I could get the elements using an other program and save them as .txt files, but it would be much more interesting to do it inside Pd.
System: Pd-Ext, W7.
There is [readanysf~ ] that gives you the correct length of an mp3, but I don't know about its availability on Windows.
I found the exiftool the best tool suited for this task. Google tells me, it is even available as a Windows binary. It determines the length correctly, no matter whether compressed as vbr or cbr.
Roman