emms-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emms-info-native and track duration


From: Yoni Rabkin
Subject: Re: emms-info-native and track duration
Date: Tue, 29 Aug 2023 16:41:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Petteri Hintsanen <petterih@iki.fi> writes:

> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> Petteri Hintsanen <petterih@iki.fi> writes:
>>
>>> On Mon, Dec 05, 2022 at 01:14:07PM -0500, Yoni Rabkin wrote:
>>>
>>>> Do you have any input or insight regarding implementation of track
>>>> duration for emms-info-native?
>>>
>>> Do you mean populating 'info-playing-time for a particular file (track)?  
>>> It can be done, but it will require scanning the whole file to get the
>>> information.  There is no duration information in the metadata.  So decoding
>>> will become somewhat slower.
>>>
>>> I can try to hack a prototype if there is a need for that.
>>
>> That would be welcome. If you already have the infrastructure to read
>> frames then a lot of the work is already done. But I realize that since
>> a lot of files are not constant bitrate, there is a good amount of
>> calculation to do.
>
> It took quite a while to get something working, but I have now
> resurrected info-native branch with code for decoding stream durations
> from ogg/opus/flac and mp3 files.  For those who are interested, please
> go ahead and test it.
>
> For ogg and flac files the calculated durations should be accurate
> within one second or so.  But MP3s are hairier, since they do not have
> any standard way to encode stream duration.  Often, one needs to
> estimate the duration, which can go off by tens if not hundreds of
> seconds.
>
> Nonetheless, for my modestly sized collection of MP3s, emms-info-native
> calculates the playing time with ±2 seconds accuracy for almost all
> files (compared against TagLib and ffmpeg).  Failing cases are those
> where the inputs are somehow garbled.  I'm not planning to fix those
> corner cases because there are so few of them.

Thank you for this; that's great work.

I haven't tested the code yet, but I intend to.

> Few more notes still:
>
> - emms-info-native.el has been split into smaller files.  Hopefully
> they are not *too* small.

They are the right size in my opinion.

As far as naming goes we'll need to make a decision. Currently the
format is emms-info-TOOLNAME, and not emms-info-FORMAT. Therefore, files
such as emms-info-mp3 should be called emms-info-native-mp3. This also
clearly indicates that they belong to emms-info-native.

What do you think?

> - There are now few ERT tests in "test" directory.  Their coverage is
> rather limited, but still better than nothing.  "Resource files" (few
> ogg/flac/mp3 test files) come from Mutagen project.  They are licensed
> under GPLv2+.  We probably need to (and definitely should) state this
> somewhere if we want to keep the files in the distribution.

We can't include those particular test files in the Emms distribution.

For one thing, they contain parts of copywritten works and therefore
cannot be actually under the GPL. "Giora Feidman - Songs of Rejoicing",
for instance, is from 1987 and is definitively not in the public domain.

Secondly, please remember that all parts of Emms have their copyright
assigned to the FSF (something that the Mutagen project probably doesn't
do.) As a consequence, I'm afraid that we'll have to remove all files
which are based on works for which the FSF cannot be assigned copyright.

-- 
   "Cut your own wood and it will warm you twice"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]