[pkg-mad-maintainers] Bug#881283: libmad0: produces different results on s390x/arm64/...

[Manuel A. Fernandez Montecelo]

Hi,

2017-11-09 17:23 IOhannes m zmoelnig:
>Package: libmad0
>Version: 0.15.1b-8.1
>Severity: important
>
>Dear Maintainer,

Not the maintainer here, and not specially interested in this package
per se, but the last upload was an NMU made by me to fix multi-arch
issues, so chiming in just in case...

I am not sure if my upload has anything to do with it, sonic-visualiser
seems to have failed before that.


>TL;DR: it seems that libmad is not really usable on s390x.
>
>i'm currently trying to find out why sonic-visualiser_3.0.3-1 fails to build
>successfully on the s390x and arm64 architectures.
>The problem is a failing test when decoding mp3 files.
>The test runs fine on most release architectures, but fails on

To see if they have anything in common, let's investigate a bit:

>- arm64

64-bit little-endian

>- s390x

64-bit big-endian

>- alpha

64-bit little-endian

>- hppa

32-bit big-endian

>- m68k

32-bit big-endian

>- sh4

32-bit little-endian


... so they don't have much in common in that respect.


>Now while trying to hunt this down, i think i found an issue with libmad.
>Using the following test-program:
>
>    #!/usr/bin/env python
>
>    import mad
>    mf = mad.MadFile("sine.mp3")
>    data = mf.read()
>
>    offset = 2048
>    print([_ for _ in data[offset:(offset+1024)]])
>
>
>and the attached minimal MP3-file "sine.mp3" i get different results for s390x
>(zelenka.debian.org) and amd64 (my laptop):
>
>s390x = [  0,   1,   0,   1, 255, 254, 255, 254, 255, 252, 255, 252, 0, 5, ...
>amd64 = [252, 255, 252, 255, 254, 255, 254, 255,   0,   0,   0,   0, 1, 0, ...
>
>I've also ran the file through the 'minimad' example that comes with libmad
>(sources), and the output differs on the two architectures (i've attached the
>results as 's390x.bin' resp.  'amd64.bin').
>i haven't done any checks on architectures that are supposed to be "ok"
>(according to my test-suite).
>
>Would it be possible to fix this?
>If not, should the failing architectures be marked as "not-for-us"?

I would be tempted to update to the latest upstream version, but the
last release was in 2004 :(

Since I never worked with this library before or know anything about the
field, I am not sure if I can do much more in this respect.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>