dir2ogg produces sped-up OGG output

[gwern]

Binary package hint: dir2ogg

gwern@craft:21801~>uname -a && lsb_release -rd && apt-cache policy dir2ogg [ 9:03PM]
Linux craft 2.6.27-3-generic #1 SMP Wed Sep 10 16:18:52 UTC 2008 x86_64 GNU/Linux
Description: Ubuntu intrepid (development branch)
Release: 8.10
dir2ogg:
  Installed: 0.11.6-1
  Candidate: 0.11.6-1
  Version table:
 *** 0.11.6-1 0
        500 http://archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

I have a particular MP3 file. It plays fine in MPlayer, so I believe it is not corrupt or anything. When I run dir2ogg on it, with or without --smart-mp3, it produces an OGG file which is roughly half the time long; that is, it is sped up approximately 2x (if I play the resulting OGG file and slow down to 0.51x, it sounds roughly right and seems to contain the full song).

This is a double bug; dir2ogg is producing incorrect output, I think, and it also isn't clearly warning about its failure. It both returns a 0 exitcode and produces no unusual warning output I haven't seen many times before. Here is an example conversion:

gwern@craft:21826~/music>=dir2ogg young_marble_giants_-_final_day.mp3 && echo foo [ 9:05PM]
dir2ogg 0.11.6 (2008-07-14), converts audio files into ogg vorbis.

High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
 version 1.4.3; written and copyright by Michael Hipp and others
 free software (LGPL/GPL) without any warranty but with best wishes

Playing MPEG stream 1 of 1: young_marble_giants_-_final_day.mp3 ...
[wav.c:362] warning: Cannot rewind WAV file. File-format isn't fully conform now.
Title: Track 15
MPEG 2.0 layer III, 56 kbit/s, 22050 Hz joint-stereo
Opening with wav module: WAV file reader
Encoding standard input to
         "young_marble_giants_-_final_day.ogg"
at quality 3.00
 Encoding [ 0m02s so far] |
[1:43] Decoding of young_marble_giants_-_final_day.mp3 finished.
[wav.c:362] warning: Cannot rewind WAV file. File-format isn't fully conform now.
 Encoding [ 0m02s so far] /

Done encoding file "young_marble_giants_-_final_day.ogg"

 File length: 0m 51.0s
 Elapsed time: 0m 02.2s
 Rate: 23.7690
 Average bitrate: 110.7 kb/s

/usr/lib/python2.5/site-packages/mutagen/_util.py:149: DeprecationWarning: 'i' format requires -2147483648 <= number <= 2147483647
  to_int_be = staticmethod(lambda data: struct.pack('>i', data))
foo

The MP3 file is attached.

[Julian Andres Klode (juliank)]

Thank you for reporting this bug. In order to solve your problems,
you need to use a different decoder for the file.

Use one of
  --mp3-decoder=lame
  --mp3-decoder=mplayer
to create a correct output file. (Use --help to see which decoders are available).

BTW, do you have any permission to distribute the MP3 file? If not, please remove it.

[gwern (gwern0)]

I tried the different decoders. Lame doesn't seem to be available; mplayer results in a correct file; and mpg123 (the other option) results in a similarly sped-up OGG file.

> BTW, do you have any permission to distribute the MP3 file? If not, please remove it.

Obviously I don't. But I have no Freely licensed examples of the problem and I would guess it's needed to solve this bug.

[Julian Andres Klode (juliank)]

The attached patch checks the length and prints warnings if lengths differ by a at least 1 second.

In your case, it prints:
 "Warning: Length changed (-51 sec). If the file does not work, try a different decoder."

Is this solution acceptable for you?

[Julian Andres Klode (juliank)]

BTW; it does not abort if the length changed, it only displays a warning.

[gwern (gwern0)]

> Is this solution acceptable for you?

It's *better*, absolutely. If a bugfix which stops the speedup is not on offer, I'll settle for a warning or error.

> BTW; it does not abort if the length changed, it only displays a warning.

Hm. Is there any circumstance in which changing the length (and warping all the music) isn't an error?

[Julian Andres Klode (juliank)]

2008/9/21 gwern <email address hidden>
>
> > Is this solution acceptable for you?
>
> It's *better*, absolutely. If a bugfix which stops the speedup is not on
> offer, I'll settle for a warning or error.
This bug can not be fixed, because it's no real bug in dir2ogg. It's
more or less a problem in mpg123.
>
> > BTW; it does not abort if the length changed, it only displays a
> warning.
>
> Hm. Is there any circumstance in which changing the length (and warping
> all the music) isn't an error?

Well, it's just really bad if you want to convert 1000 files and it
aborts just because one file is bad.
Therefore, dir2ogg just displays warnings.
--
Julian Andres Klode - Free Software Developer
  Debian Maintainer - Contributing Member of SPI
  Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/ XMPP: <email address hidden>
Debian: http://www.debian.org/ SPI: http://www.spi-inc.org/
Ubuntu: http://www.ubuntu.com/ FSFE: http://www.fsfe.org/

[Julian Andres Klode (juliank)]

>
> > Is this solution acceptable for you?
>
> It's *better*, absolutely. If a bugfix which stops the speedup is not on
> offer, I'll settle for a warning or error.
This bug can not be fixed, because it's no real bug in dir2ogg. It's
more or less a problem in mpg123.

> Hm. Is there any circumstance in which changing the length (and warping
> all the music) isn't an error?
Well, it's just really bad if you want to convert 1000 files and it aborts just because one file is defect.
Therefore, dir2ogg just displays warnings.

[Alexey Karpov (alexeydk78-gmail)]

I think this bug may happen because dir2ogg not care about number of channels in input mp3 - when decoding mono input through stdin oggenc not supplied with -C 1 parameter. This leads to encode mono stream as stereo. Now I try to fix this and will send patch there, if succeed.

Sorry for my bad english.

[Alexey Karpov (alexeydk78-gmail)]

I add setting parameter -C to oggenc based on mp3info.info.mode from mutagen. My changes applies only to converting mp3 through stdin/stdout, also I add info line with number of detected channels. Please review my changes. I tested it on my mono/stereo mp3's and all be allright.

It's my first attempt of working on opensource and using diff, then tell me if i got any errors!

[Julian Andres Klode (juliank)]

1) you added the code to the smart mp3 function. Therefore, it's only enabled
    when --smart-mp3 is activated.
2) you did the following: mode in ('STEREO', 'JOINTSTEREO', 'DUALCHANNEL')
    This is wrong. STEREO, etc. are variables of mutagen.mp3 and represent an
    integer value.
3) the program would fail on every non-mp3 because self.conf.channels is not set.
4) It works with lame, therefore mpg123 should be fixed, not dir2ogg.

[gwern (gwern0)]

> This bug can not be fixed, because it's no real bug in dir2ogg. It's
more or less a problem in mpg123.

So, what next, Julian? Should someone reassign this bug report to mpg123 or is Alexey right and this is actually a dir2ogg problem?

[Alexey Karpov (alexeydk78-gmail)]

I have studied attached mp3 and, i think, have found in what a problem. It is similar to about what I wrote, but instead of number of channels here it is a question of frequency of digitization.

The file is coded with frequency of 22050 Hz, with such frequency mpg123 plays it, but oggenc on-default means frequency of 44100 Hz, and a parameter -R to it is not set. Therefore the coded file playing twice faster.

[Julian Andres Klode (juliank)]

------------------------------------------------------------
revno: 63
committer: Julian Andres Klode <email address hidden>
branch nick: dir2ogg
timestamp: Sun 2009-05-03 15:34:09 +0200
message:
  * Fix problems with mpg123 and files not using 44100Hz (LP: #272341)

[Julian Andres Klode (juliank)]

dir2ogg (0.11.7) RELEASED; urgency=low

  * Recognize the track number in mp3 files
  * Fix problems with mpg123 and files not using 44100Hz (LP: #272341)
  * Make --preserve-wav work when using mplayer (Closes: #513566)
  * Fix problem where tags from one file appear in other files (LP: #276037)
  * Inform people that converting CDs is not well supported.

 -- Julian Andres Klode <email address hidden> Sun, 03 May 2009 14:45:59 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package dir2ogg - 0.11.7-1

---------------
dir2ogg (0.11.7-1) unstable; urgency=low

  * New bugfix release:
    - Fix problems with mpg123 and files not using 44100Hz (LP: #272341)
    - Make --preserve-wav work when using mplayer (Closes: #513566)
    - Fix problem where tags from one file appear in other files (LP: #276037)
  * Some packaging changes:
    - Move all CD-related dependencies from Recommends to Suggests
    - Update e-mail address
    - Update to Standards-Version 3.8.1

 -- Ubuntu Archive Auto-Sync <email address hidden> Mon, 04 May 2009 08:22:27 +0100

[David Futcher (bobbo)]

I don't see any evidence in here that this is a bug in mpg123 and I see a Fix Released both upstream and in ubuntu for dir2ogg, so I will mark the mpg123 task as Invalid. If this is a bug in mpg123, please re-open the bug. Thanks!

[Julian Andres Klode (juliank)]

David Futcher wrote:
> I don't see any evidence in here that this is a bug in mpg123 and I
> see a Fix Released both upstream and in ubuntu for dir2ogg,
> so I will mark the mpg123 task as Invalid

The fix in dir2ogg should really be considered a work around. It is just passing the sample rate of the MP3 to mpg123 via the -R option. mpg321 does not require this.

[Julian Andres Klode (juliank)]

> The fix in dir2ogg should really be considered a work around. It is
> just passing the sample rate of the MP3 to mpg123 via the -R
> option. mpg321does not require this.
OK, -R is passed to oggenc. mpg123 outputs streams with the same sample rate as the input, whereas the other decoders use 44100Hz.