RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 751066 - magic_buffer doesn't recognize mp3
Summary: magic_buffer doesn't recognize mp3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: file
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Kaluža
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-03 12:23 UTC by Stanislav Oginsky
Modified: 2011-11-08 08:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-08 08:07:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
requested mp3 file (3.23 MB, audio/mpeg)
2011-11-07 11:09 UTC, Stanislav Oginsky 		no flags Details
View All

Description Stanislav Oginsky 2011-11-03 12:23:38 UTC 
Description of problem:

I have found that "sox" utility that is consumer of "file" (libmagic) can't recognize mp3 files via magic_buffer.
The issue however appears in file-5.0.4 but is not reproducible using file-4.17

How reproducible:
It is reproducible for some mp3 files (not all of them). 

Just use some mp3 file and try to get it's file type by using magic_buffer and magic_file:

The example is like:
===
        filetype_file = magic_file(magic, "filename");
        if (filetype_file)
                printf("FILE: %s\n", filetype_file);

        if (magic)
                filetype = magic_buffer(magic, data, len);
        if (filetype)
                printf("BUFFER: %s\n", filetype);

===

Actual results:
It does determine the file type with magic_file only.
With file-4.17 it determine file type with both.

Expected results:

To get correct file type using magic_buffer.

Additional info:

My mp3 info extracted using sox:
===
arch:  1288 48 88 L OMP
sox INFO formats: detected file format type `audio/mpeg'
sox DBUG mp3-duration: got exact duration from XING frame count (3854)

Input File     : 'Vanishing.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:01:40.68 = 4439768 samples = 7550.63 CDDA sectors
File Size      : 3.39M
Bit Rate       : 269k
Sample Encoding: MPEG audio (layer I, II or III)

Output File    : '' (null)
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:01:40.68 = 4439768 samples = 7550.63 CDDA sectors

sox INFO sox: effects chain: input      44100Hz 2 channels 16 bits (multi)
sox INFO sox: effects chain: output     44100Hz 2 channels 16 bits (multi)
===

Please inform me if additional information is required and if I should send you mp3 file for test.

Thank you in advance.
Comment 2 RHEL Program Management 2011-11-03 12:49:00 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 3 Jan Kaluža 2011-11-04 06:14:07 UTC 
What's exactly "file" package version you have?
Comment 4 Stanislav Oginsky 2011-11-04 06:58:33 UTC 
The version is:
file.x86_64 5.04-9.el6
Comment 5 Jan Kaluža 2011-11-07 09:41:41 UTC 
Hm, I was trying to reproduce it and some not-working mp3 file would help me.
Comment 6 Stanislav Oginsky 2011-11-07 11:09:56 UTC 
Created attachment 532013 [details]
requested mp3 file

The file is enclosed.
Comment 7 Jan Kaluža 2011-11-07 12:41:14 UTC 
What sox version do you have? My test app detects it properly. I have never used sox, but as far as I understand, official sox in RHEL does not have MP3 support.
Comment 8 Stanislav Oginsky 2011-11-07 12:53:13 UTC 
Sox has smart system of detection, if file has extension sox will detect it, but it won't use magic, please remove the extension and try again.
sox -V6 --magic Vanishing -n

However even if you don't do so you may see that format wasn't detected:
> sox -V6 --magic Vanishing -n
sox: SoX v14.3.2
time:  Jun 29 2011 11:20:29
gcc:   4.4.5 20110214 (Red Hat 4.4.5-6)
arch:  1288 48 88 L OMP
sox DBUG formats: libmagic detected application/octet-stream; charset=binary                                 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sox FAIL formats: can't determine type of file `Vanishing'

And SoX 14.3.2 has magic support.

Moreover it does detect the format if magic_file is used instead of magic_buffer.

Please inform me if you need additional information.
Comment 9 Jan Kaluža 2011-11-08 08:07:28 UTC 
You are not using sox from RHEL6 or Fedora, because it's not compiled with libmagic support and it's also not version 14.3.2.

However, I've checked the code of 14.3.2 and it passes only 256 bytes of file to magic_buffer function, which is not enough. It should pass 4096 bytes there. I've successfully reproduced it with my test script.

So, in sox in formats.c, there should be:
#define AUTO_DETECT_SIZE 4096
instead of 
#define AUTO_DETECT_SIZE 256

Since this is not File bug and it also doesn't affect RHEL/Fedora sox packages (because there's no libmagic support in them), I will close it as NOTABUG. If you're familiar with sox upstream, you can submit it as a bug there.
Note You need to log in before you can comment on or make changes to this bug.