Discussion:
Can't seek in AAC files
Philipp Hartwig
2011-05-15 18:19:26 UTC
Permalink
Hi,

I often download YouTube videos with youtube-dl[1]. Normally the audio
stream is in the AAC format which I then extract with

$ ffmpeg -i foo.flv -acodec copy foo.aac

from the downloaded YouTube video foo.flv. cmus will play the file
foo.aac but it doesn't seem to be able to seek in it: The seek commands
simply don't show any effect.

I don't have any other AAC files to test with so I don't know whether
this is specific to the ones from YouTube. I would provide a file for
testing but I'm not sure I'm allowed to do this (copyright etc.). If you
need further information in order to determine what's going on I'll be
glad to be of assistance. I'm using cmus 2.4.0 on Debian.

Regards,
Philipp

[1] http://rg3.github.com/youtube-dl/
Johannes Weißl
2011-05-15 21:09:53 UTC
Permalink
Hello Philipp,
Post by Philipp Hartwig
I often download YouTube videos with youtube-dl[1]. Normally the audio
stream is in the AAC format which I then extract with
$ ffmpeg -i foo.flv -acodec copy foo.aac
from the downloaded YouTube video foo.flv. cmus will play the file
foo.aac but it doesn't seem to be able to seek in it: The seek commands
simply don't show any effect.
Yes, seeking in AAC is not supported... but since e.g. VLC can seek, it
is definitely possible - somebody has to code it :-)!

I attached a patch that displays an error message in this case, it
should not fail silently. Thanks for the report! I added an item to the
TODO list:
http://cmus.sourceforge.net/wiki/doku.php?id=todo


Greetings,
Johannes
Gregory Petrosyan
2011-05-16 13:04:13 UTC
Permalink
Post by Johannes Weißl
Hello Philipp,
Post by Philipp Hartwig
I often download YouTube videos with youtube-dl[1]. Normally the audio
stream is in the AAC format which I then extract with
$ ffmpeg -i foo.flv -acodec copy foo.aac
from the downloaded YouTube video foo.flv. cmus will play the file
foo.aac but it doesn't seem to be able to seek in it: The seek commands
simply don't show any effect.
Yes, seeking in AAC is not supported... but since e.g. VLC can seek, it
is definitely possible - somebody has to code it :-)!
I attached a patch that displays an error message in this case, it
should not fail silently.
Thanks a lot, merged!

                Gregory
Johannes Weißl
2011-05-17 01:43:30 UTC
Permalink
Hello Philipp,
Post by Philipp Hartwig
I often download YouTube videos with youtube-dl[1]. Normally the audio
stream is in the AAC format which I then extract with
$ ffmpeg -i foo.flv -acodec copy foo.aac
from the downloaded YouTube video foo.flv. cmus will play the file
foo.aac but it doesn't seem to be able to seek in it: The seek commands
simply don't show any effect.
Sorry, there is of course a much simpler solution to your problem:
$ MP4Box -add foo.aac foo.m4a

This doesn't change the AAC data (no quality loss), and seeking in m4a
files is supported! The MP4Box command is from the "gpac" package.


Johannes
Philipp Hartwig
2011-05-17 07:23:24 UTC
Permalink
Hello Johannes,
Post by Johannes Weißl
$ MP4Box -add foo.aac foo.m4a
This doesn't change the AAC data (no quality loss), and seeking in m4a
files is supported! The MP4Box command is from the "gpac" package.
that's a great idea, thank you. I have some trouble installing gpac
because of incompatible versions of ffmpeg in debian-multimedia. That's
why I've had a look at "mkvmerge" from the "mkvtoolnix" package instead
and this also seems to work nicely. I'm using
$ mkvmerge -o foo.mka foo.aac
now.

And with a file foo.xml such as

--- SNIP ---
<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>ARTIST</Name>
<String>Tori Amos</String>
</Simple>
<Simple>
<Name>ALBUM</Name>
<String>Under the Pink</String>
</Simple>
<Simple>
<Name>TRACK</Name>
<String>2</String>
</Simple>
<Simple>
<Name>TITLE</Name>
<String>Cornflake Girl</String>
</Simple>
</Tag>
</Tags>
--- SNAP ---

and the command
$ mkvmerge --global-tags foo.xml -o foo.mka foo.aac
cmus will even recognize the tags. Awesome.

Thanks again.

Best regards,
Philipp

Continue reading on narkive:
Loading...