#7047 closed bug (fixed)
Noisy AIFF audio files
| Reported by: | humdinger | Owned by: | stippi |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Audio & Video/Codecs | Version: | R1/Development |
| Keywords: | Cc: | degea@…, bga@… | |
| Blocked By: | #7900 | Blocking: | #7677, #7679, #9939 |
| Platform: | All |
Description
This is hrev39962.
AIFF audio files play extremly noisy in MediaPlayer. VLC plays without noise, but with major stutters. I think sample files are too big to be attached to a ticket, you'll find many examples at the site SimpyTheBest.
Attachments (2)
Change History (20)
comment:2 by , 14 years ago
Ok after a bit mor einvestigation on my end. I did check these files in a few DAW's I use, these are very poorly encoded files, very high noise floor, loads of gain. I think something in ffmpeg is attempting to normalize the gain leve or add gain and its making a bad sound file horrific.
Not really sure what to suggest here. Haiku should be able to play very lossy sounding files. But on the other hand, lossy files are really obnixous. But mediaplayer is not handling these files correctly.
comment:3 by , 14 years ago
I converted a hi-quality file with Audacity under Ubuntu to AIFF(16bit PCM), 44.1kHz, stereo. Where the low-quality examples (11kHz, mono) produce noise, these new ones call the gdb right from the start:
[tcsetpgrp failed in terminal_inferior: Invalid Argument] Thread 306 called debugger(): Decoder didn't set raw audio output buffer size [...] [Switching to team /boot/system/apps/MediaPlayer (301) thread playback manager (306)] 0xffff0114 in ?? () (gdb) bt #0 0xffff0114 in ?? () #1 0x00959d3b in debugger () from /boot/system/lib/libroot.so #2 0x0058b560 in BMediaTrack::DecodedFormat () from /boot/system/lib/libmedia.so #3 0x0026263c in MediaTrackAudioSupplier::_InitFromTrack () #4 0x00262a31 in MediaTrackAudioSupplier::MediaTrackAudioSupplier () #5 0x00260c89 in MediaFileTrackSupplier::CreateAudioTrackForIndex () #6 0x0026d68e in Controller::SelectAudioTrack () #7 0x0026e962 in Controller::SetTo () #8 0x0026e9f8 in Controller::MessageReceived () #9 0x0034f5b8 in BLooper::DispatchMessage () from /boot/system/lib/libbe.so #10 0x003510f4 in BLooper::task_looper () from /boot/system/lib/libbe.so #11 0x00350e1a in BLooper::_task0_ () from /boot/system/lib/libbe.so #12 0x0095dbd0 in thread_entry () from /boot/system/lib/libroot.so #13 0x70080fec in ?? ()
comment:5 by , 13 years ago
| Blocking: | 7679 added |
|---|
comment:6 by , 13 years ago
| Cc: | added |
|---|
I asked dsuden about the "gain" thing but apparently high-quality AIFF files play just static too, so it's not a case of ffmpeg being half-wrong or picky, the bug seems much more heavy in consequences..
follow-up: 9 comment:7 by , 13 years ago
Checking the encoding quality is all fine but, if you check the bug I created (#7900) you will see a sample file that used to play fine in haiku and now does not. So the problem does seem to be some change in the media codecs and not a problem with specific files.
comment:8 by , 13 years ago
| Cc: | added |
|---|
comment:9 by , 13 years ago
Replying to bga:
if you check the bug I created (#7900) you will see a sample file that used to play fine in haiku and now does not
Bruno any idea (even very rough) when was the last year/month that this worked in Haiku?
Update: just checked the change history in addons/media/plugins/aiff_reader and apparently it has had almost zero change in the last 6 years..!
So I suspect the answer to my question is "when we switched over to ffmpeg" or something eh :-) ?
Could the devs make the Media Kit use the 'old' decoder/reader, while the ffmpeg guys fix their code (I assume this latter one is an external project outside of the control of Haiku devs) ?
comment:10 by , 13 years ago
| Cc: | added; removed |
|---|
Sorry, I have no idea. I did not run Haiku at all for a long time and just now resumed playing with it.
There is probably a way to change the priority for a specific media type. stippi would know how to do that.
comment:11 by , 13 years ago
Investigated some more and now I'm back with good steps toward resolving this ticket (I think).
Didn't find prioritizing of plugins, but -- Found two possibles fixes, one of which I've successfully tested: I'm now successfully playing AIFF files on R1A3 again, thanks to the 'native' (pre-ffmpeg) reader. So there are two ways to fix this I guess:
Option 1:
Upgrade ffmpeg to a more recent build, as it might fix AIFF support (and maybe the WAV and mp3 problems reported in other tickets too, who knows). Indeed, there are 2 tickets in the ffmpeg "trac" that are related to AIFF files:
http://ffmpeg.org/trac/ffmpeg/ticket/62 (closed as fixed) http://ffmpeg.org/trac/ffmpeg/ticket/204 (open enhancement)
Option 2:
(A more immediate, easy fix, successfully tested here) -- restore the original Haiku AIFF reader:
- make it part of the build, presumably by appending "aiff_reader" to HaikuImage:146
- make ffmpeg decline support of AIFF files, presumably by commenting out CodecTable.cpp:23 and maybe another line down this file; maybe this step can be ommited as I've noticed that ffmpeg sometimes gets "pre-empted" by aiff_reader even without doing this step, when BFS does return plugins in lexical order -- but this is not reliable, to say the least. It would be best to outright disable AIFF support in ffmpeg to make sure the aiff_reader is the one that handles this format no matter what.
So basically, AIFF support can be back in Haiku with one (or two) one-liner modifications.. Hopefully this ticket can be closed soon ;-) in the meantime I can send the compiled aiff_reader to dsuden to unblock him.
comment:12 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:13 by , 13 years ago
dsuden just tried the recent hrev43888 [which includes an earlier] upgrade of the ffmpeg package but no change for him... His media_server is a bit shaky so I should test on my own too just to be safe.
by , 12 years ago
| Attachment: | MediaPlayer-847-debug-04-03-2013-17-06-13.report added |
|---|
MP crashes on the sample AIFF file from ffmpeg ticket 204
comment:14 by , 12 years ago
Still there in hrev45325 . Tried the file from the ffmpeg ticket and now it crashes (see attached). I don't think it did before (?). Would try a gcc4 build of Haiku, but I guess it wouldn't help since this is not a compilation problem or stack alignment problem but something else at play here..
by , 11 years ago
| Attachment: | RisingSunIntroL.aiff added |
|---|
AIFF with (non-standard) little-endian data that plays in Haiku
comment:15 by , 11 years ago
Is anybody looking at this? I've found out exactly why AIFF files sound like white noise, anyway. The endianness of the samples is not recognized! AIFF data is always big-endian, but ffmpeg seems to be assuming they are little-endian. (AIFC files can be little-endian, and somewhere I read that these can sound like noise in a standard AIFF player, which led me to this realization.)
After a bit of fiddling with sox, I generated an "AIFF" file with little-endian samples (attached), and MediaPlayer handles it just fine!
Not sure where the fix now lies, but Ihope that's helpful.
comment:16 by , 10 years ago
| Blocked By: | 7900 added |
|---|
comment:18 by , 10 years ago
| Blocking: | 9939 added |
|---|
Humdinger I don't know alot about code, but for sure thats digital distortion in mediaplayer. The gain is to high on the AIFF format. I know that sound clear as day. I didn't try with vlc but likely vlc has a better noise floor and is likely just digitally clipping. the other thing I am clearly hearing in VLC, I'd have to test these files on a known good media player under windows to confirm this, is that the compression/decompression algorythm was rather poor, encoding artifact present everywhere.