FFSoX Player is a Winamp (http://www.winamp.com/ (http://www.winamp.com/)) plug-in based on the FFmpeg (http://www.ffmpeg.org/ (http://www.ffmpeg.org/)) and SoX (http://sox.sourceforge.net/ (http://sox.sourceforge.net/)) libraries. Using FFmepg almost all multimedia files may be played, including but by far not restricted to H.264 and VP8. Audiophile sound processing is provided using high quality 32 bit SoX algorithms and dithering.
Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Project: http://sourceforge.net/projects/in-ffsox/ (http://sourceforge.net/projects/in-ffsox/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)
thanks a lot...
_
Just released v0.2:
http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)
What's new?
- Now with installer.
- Now with (minimal) FFmpeg for playing OGG (both Vorbis audio and Theora video ) and WebM (Vorbis audio and VP8 video, the latest one from Google)
Note the SoX options (replay gain and re-sampling to double sample rate) to get real hifi out of Winamp.
Would be glad to get some feedback from you.
Peter
Released v0.3Got a feature request (http://sourceforge.net/tracker/?func=detail&aid=3024963&group_id=328545&atid=1378696) on SourceForge this morning:
So far winamp lacks any resampling plugin that resamples audio. This is useful for people who have the soundblaster audigy series, which forces audio playback in 48Khz, and any audio not at that resolution will get resampled by the APU, which is horrible in the audigy series. Besides that, some others, although having good cards, may prefer resampling techniques done in software instead of hardware. As far as I know, one of the more prominent resamplers for foobar2000 was based on SoX algorithms, so I hope that this could be implemented in this plugin as well. Thank You
In response I've created v0.3 (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.3/in_ffsox-0.3.exe/download) making almost all SoX resampling options available to the user. For details cf.
- http://in-ffsox.sourceforge.net/#sox (http://in-ffsox.sourceforge.net/#sox)
- http://in-ffsox.sourceforge.net/#sox-resample (http://in-ffsox.sourceforge.net/#sox-resample)
Download: http://sourceforge.net/projects/in-ffsox/f....3.exe/download (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.3/in_ffsox-0.3.exe/download)
v0.4 releasedWhat's new?
- Enabled seeking (depends on whether the corresponding FFmpeg format supports it).
- Made switching on/off the gain effect's limiter available in configuration dialog.
- Resolved some issues which caused the plug-in to crash in case of unsupported codecs.
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
v0.4.1 releasedWhat's new?
- Support for "avcore-0.dll" (new FFmpeg library, has to be copied along the other DLLs if using FFmpeg from third party sites, e.g. http://ffmpeg.arrozcru.org/autobuilds/ (http://ffmpeg.arrozcru.org/autobuilds/)).
- Resolved some video synchronization issues.
- Switch on/off SoX decoders via configuration.
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
works nice, the only thing I didnt like - it is downloading full file and utilize full network bandwidth for http input (instead of buffering/pre-buffering)
(standard plugin in_mp3 dll have buffering options with data size limits, which results in low network usage during playback of streams and http links)
when this is useful? trying to play mp4 (audio podcast) by adding urls to playlist, sometimes use seeking...
I have checked ffplay (ffmpeg) and mplayer (uses libavcodec) - they both have some http buffering feature, and not trying to download whole file
it is downloading full file and utilize full network bandwidth for http input (instead of buffering/pre-buffering)
(standard plugin in_mp3 dll have buffering options with data size limits, which results in low network usage during playback of streams and http links)
I'm not aware that this plug-in supports streaming yet (uses
av_open_input_file()), hence I have no idea how to test it. Could you please give an example?
my previous message was a inaccurate, it looks like mp4 was played via another plugin, and your plugin do not accept mp4 stream input
but your plugin accept ogg stream (http file link with ogg encoded podcast) input, and plays it on wrong speed
I send you pm with examples of http links (if you want to check it, but this features are not very important anymore:
I have re-checked winamp default plugins: mp4 supported with streaming and unbuffered seeking, ogg supported with streaming but not seeking)
also it is a little bit annoying to have flashing black console windows (which instantly disappear)
dont work flac winamp seek bar...
I send you pm with examples of http links
Thanks a lot.
your plugin do not accept mp4 stream input
MP4 is not supported by default. To activate it you should do the following:
- Goto http://ffmpeg.arrozcru.org/autobuilds/ (http://ffmpeg.arrozcru.org/autobuilds/) and download the latest "shared w32" build.
- Extract (by using 7z (http://www.7-zip.org/)) the DLLs from the 7z-archive's "bin" folder into "<Winamp>/Plugins/in_ffsox".
- Add MP4 to the plugins extensions via configuration dialog.
- Disable the default MP4 plugin, e.g. by renaming "in_mp4.dll" to "in_mp4.dll.X".
your plugin accept ogg stream (http file link with ogg encoded podcast) input, and plays it on wrong speed
I have no idea how you achieve this. The only thing I can imagine is the following:
it is a little bit annoying to have flashing black console windows (which instantly disappear)
The plugin is based on FFmpeg and SoX. Both provide an input layer. By default the plugin first tries to open a file via SoX and if not successful in a second try via FFmpeg. As far as I can see the black window comes from SoX trying to download the file using wget (http://en.wikipedia.org/wiki/Wget). In your environment this seems to be successful.
It is possible to switch off the SoX input layer via the plugin's preferences dialog. As far as I can see, if SoX input is switched off no streaming is possible, no black window appear.
Meanwhile I convinced myself that command line FFmpeg supports streaming. This gives rise to the assumption that the plugin will support real streaming (as opposed to SoX download) somewhere in the future.
I was able to reproduce that seeking OGG files is buggy. Hopefully this will be fixed in the near future.
dont work flac winamp seek bar...
From my limited understanding of SoX and FFmpeg I have the following impression:
- SoX doesn't support seeking at all.
- FFmpeg's FLAC demuxer doesn't support seeking (cf. "libavformat/flacdec.c").
Somebody out there who could proof me wrong?
v0.4.2 releasedWhat's new?
- Fixed seeking OGG (and possibly other formats).
- Verified that streaming (e.g. via HTTP) is supported. For streaming "SoX decoder" in preferences should be switched off.
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
v0.4.2 released
There where some issues reported with the binaries compiled on a Vista/64 system. I've just uploaded new binaries compiled on a XP/32 system which should do better.
Sorry for any inconvenience.
Very interesting project, congratulations!
some small report in a hurry
- mp3 - seeking does not work, ape2 tags are not recognized. This is not important at all, because I doubt that somebody will replace the original nullsoft plugin, but might give you some hints if something is not working as expected;
- ogg (with tags) crash the WA 5.581, didn't crash 5.71. Not a big issue since there is an official plugin from nullsoft;
- both musepack sv7 and sv8 formats crash WA at EOF (with WA 5.71 only sv8 format had problems). This is important, because there is no official stable plugin from nullsoft.
- rg data ae not recognized for any file I've tested.
Cheers
Very interesting project, congratulations!
Thank you
- mp3 - seeking does not work, ape2 tags are not recognized. This is not important at all, because I doubt that somebody will replace the original nullsoft plugin, but might give you some hints if something is not working as expected;
This plug-in is heaviliy based on FFmpeg. The idea ist to let all this decoding stuff done by FFmpeg and only use FFmpeg's format independent API. Put into other words, all these features depend on what is implemented in FFmpeg.
FFmpeg's MP3 demuxer doesn't provide seeking yet:
AVInputFormat mp3_demuxer = {
"mp3",
NULL_IF_CONFIG_SMALL("MPEG audio layer 2/3"),
0,
mp3_read_probe,
mp3_read_header,
mp3_read_packet,
.flags= AVFMT_GENERIC_INDEX,
.extensions = "mp2,mp3,m2a", /* XXX: use probe */
.metadata_conv = ff_id3v2_metadata_conv,
};
The OGG demuxer instead does:
AVInputFormat ogg_demuxer = {
"ogg",
NULL_IF_CONFIG_SMALL("Ogg"),
sizeof (struct ogg),
ogg_probe,
ogg_read_header,
ogg_read_packet,
ogg_read_close,
ogg_read_seek,
ogg_read_timestamp,
.extensions = "ogg",
.metadata_conv = ff_vorbiscomment_metadata_conv,
.flags = AVFMT_GENERIC_INDEX,
};
The MP3 demuxer's "metadata_conv" is set to "ff_id3v2_metadata_conv", obviously only ID3v2.
FFmpeg is a very vital project. Propably someday all the missed features will be implemented. The FFSoX Player plug-in is only some kind of glue bringing FFmpeg into Winamp.
- ogg (with tags) crash the WA 5.581, didn't crash 5.71. Not a big issue since there is an official plugin from nullsoft;
- both musepack sv7 and sv8 formats crash WA at EOF (with WA 5.71 only sv8 format had problems). This is important, because there is no official stable plugin from nullsoft.
First I have to have a closer look at this.
- rg data ae not recognized for any file I've tested.
I run this plug-in myself using replay gain, especially for FLAC and MP3, and it seems to work. Which formats are you using?
v0.4.3 releasedWhat's new?
- Fixed reading metadata from OGG/Vorbis.
- Fixed Musepack SV7 and SV8 formats crashing at the end of a track.
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
Thank you for your work, now Musepack playback is fine. However, tags and RG are still not recognized (or at least not displayed).
Please, see below what I mean.
(http://ant0nski.hit.bg/temp/ffsox_mpc.jpg).
BTW, I don't use ASIO4ALL, just your input plugin with latest ffmpeg shared libs. I don't believe this could be the reason, but I might be wrong?
~
However, tags and RG are still not recognized (or at least not displayed).
Unfortunately this seems to be true for SV8 because currently FFmpeg seems not to support tags for SV8. Hopefully a FFmpeg devolper will pick up some day.
According to my tests tags should work for SV7.
According to my tests tags should work for SV7.
Well, not really:
(http://ant0nski.hit.bg/temp/ffsox_mpc7.jpg)
But even if the tags reading is not implemented by ffmpeg, the RG is not stored in tags. For Musepack RG is stored in the file header.
Anyhow, I understand that all these issues are probably due to the incomplete ffmpeg implementation, so it is not in your power to fix them.
Thanks and good luck.
But even if the tags reading is not implemented by ffmpeg, the RG is not stored in tags. For Musepack RG is stored in the file header.
Of course, I'm no Musepack expert and don't use Musepack myself.
I've replay gained SV7 using the following script mainly based on WaveGain (http://www.rarewares.org/others.php) and SED (http://www.gnu.org/software/sed/manual/sed.html):
#!/bin/sh
IFS="
"
table=`wavegain -a *.wav 2>&1|tr "\t" " "`
pat1=""
pat1="${pat1}^[ ]*Recommended Album Gain:[ ]*" # eat white
pat1="${pat1}\([^ ]*\)" # col #1: gain
pat1="${pat1}[ ]*dB[ ]*Scale:[ ]*" # eat white
pat1="${pat1}\([^ ]*\)" # col #2: scale
pat1="${pat1}.*$" # eat white
album_gain=`echo "${table}"|sed -n "s/${pat1}/\1/p"`
echo "album gain: ${album_gain} dB"
pat2=""
pat2="${pat2}^[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #1: gain
pat2="${pat2}[ ]*dB[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #2: peak
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #3: scale
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #4: new peak
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #5: left dc offset
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #6: right dc offset
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #7: track
pat2="${pat2}.*$" # eat white
for track in `echo "${table}"|sed -n "s/${pat2}/\7/p"`; do
track_gain=`echo "${table}"|grep "${track}"|sed -n "s/${pat2}/\1/p"`
echo "track: ${track}, track gain: ${track_gain} dB"
mppenc \
--tag "REPLAYGAIN_ALBUM_GAIN=${album_gain} dB" \
--tag "REPLAYGAIN_TRACK_GAIN=${track_gain} dB" \
--overwrite \
${track}
done
Maybe it's not standards to store RG values in tags but it seem to work.
Anyhow, I understand that all these issues are probably due to the incomplete ffmpeg implementation, so it is not in your power to fix them.
The plug-in has a hidden feature to work around missing tags or missing tag implementations. I've created it mainly to RG various video formats which doesn't provide RG at all. Maybe it helps also in your case.
The feature consists in providing a file "folder.csv" for each folder containing multi media files you want to "pseudo" tag. The file "folder.csv" has the following format:
[blockquote]The first line is a header listing tabulator separated the tags. Currently the haeder has to list the following tags exactly in the given order separated by tabulator:
- file
- artist
- album
- year
- track
- title
- comment
- genre
- replaygain_track_gain
- replaygain_album_gain
- albumartist
- composer
- publisher
- disc
- bpm
The following lines have to list the corresponding values for each file to be pseudo tagged, possibly empty, separated by tabulators.[/blockquote]The following script demonstrate how to pseudo tag Musepack SV8:
#!/bin/sh
IFS="
"
# run wavegain analysis and store result into ${table} for later use.
table=`wavegain -a *.wav 2>&1|tr "\t" " "`
# define pattern for album related values.
pat1=""
pat1="${pat1}^[ ]*Recommended Album Gain:[ ]*" # eat white
pat1="${pat1}\([^ ]*\)" # col #1: gain
pat1="${pat1}[ ]*dB[ ]*Scale:[ ]*" # eat white
pat1="${pat1}\([^ ]*\)" # col #2: scale
pat1="${pat1}.*$" # eat white
album_gain=`echo "${table}"|sed -n "s/${pat1}/\1/p"`
echo "album gain: ${album_gain} dB"
# define pattern for track related values.
pat2=""
pat2="${pat2}^[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #1: gain
pat2="${pat2}[ ]*dB[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #2: peak
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #3: scale
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #4: new peak
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #5: left dc offset
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #6: right dc offset
pat2="${pat2}[ ]*|[ ]*" # eat white
pat2="${pat2}\([^ |]*\)" # col #7: track
pat2="${pat2}.*$" # eat white
# create "folder.csv" and write header to it.
header="file"
header="${header}\tartist"
header="${header}\talbum"
header="${header}\tyear"
header="${header}\ttrack"
header="${header}\ttitle"
header="${header}\tcomment"
header="${header}\tgenre"
header="${header}\treplaygain_track_gain"
header="${header}\treplaygain_album_gain"
header="${header}\talbumartist"
header="${header}\tcomposer"
header="${header}\tpublisher"
header="${header}\tdisc"
header="${header}\tbpm"
echo -e "${header}" > folder.csv
# for each track ...
for track in `echo "${table}"|sed -n "s/${pat2}/\7/p"`; do
# get current track gain.
track_gain=`echo "${table}"|grep "${track}"|sed -n "s/${pat2}/\1/p"`
echo "track: ${track}, track gain: ${track_gain} dB"
# encode current track.
mpcenc --overwrite ${track}
# append a row corresponding to current track into "folder.csv"
row="`basename ${track} .wav`.mpc" # file
row="${row}\t" # artist
row="${row}\t" # album
row="${row}\t" # year
row="${row}\t" # track
row="${row}\t" # title
row="${row}\t" # comment
row="${row}\t" # genre
row="${row}\t${track_gain} dB" # replaygain_track_gain
row="${row}\t${album_gain} dB" # replaygain_album_gain
row="${row}\t" # albumartist
row="${row}\t" # composer
row="${row}\t" # publisher
row="${row}\t" # disc
row="${row}\t" # bpm
echo -e "${row}" >> folder.csv
done
Hello,
Tagging Musepack files with RG values is not correct. Musepack is designed with native RG support, that's why the RG data are stored in the header. You can find the specification here (http://trac.musepack.net/trac/wiki/SV8Specification)
In order to apply correctly RG data to the file one should use mpcgain (cli) or music organizers as Foobar, MusicBee etc.
On the other hand, APEv2 is the only allowed tag system to store metadata in Musepack files, so I don't think that it is acceptable to use some workarounds.
Whell, it seems that mpc support needs too much efforts, so don't loose your time. There are already two ways of playing mpc files on Winamp, but they are not perfect. The first one is by using the unofficial plugin from mpc developers. However, this plugin does not support transcoding (not that I would use it anyway) and some other new features of WA5.
The other way is by the DS plugin + DS filters, but in this way WA does not show the tags (although other players with DS support show them).
I hoped that your plugin will become the new official way to play mpc files, but it seems that the ffmpeg really provide very basic implementation, so don't bother with that.
Anyway, I don't use WA anymore, this request was more because of my wife .
Thank you for your support, Antonski.
The other way is by the DS plugin + DS filters, but in this way WA does not show the tags (although other players with DS support show them).
That's exactly why the currently undocumented feature described above is intentionally a major feature of the FFSoX Player plug-in. It allows you to RG your music clips as well and to shuffle them through the same playlist as any other audio file. Up to now I couldn't figure out whether there is any video format (VOB, AVI, MKV, etc.) at all supporting RG or even allow to set the corresponding tags. Could somebody help out with some respective information?
Anyway, I don't use WA anymore, this request was more because of my wife .
I'm using WA because it allows playing video clips along audio. Not to forget it's API
v0.4.4 releasedWhat's new?
- Changed order of applying the replay gain and resampling effects. Resampling is now the first effect.
- The stereo (2.0) audio stream is preferred over any other audio stream.
- Added an "Objectives" (http://in-ffsox.sourceforge.net/#objectives) section to the documentation describing the objectives why we are developing the the plug-in (currently only with respect to audio processing).
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
Thank you so much for this - it's made a world of difference with my setup (emu 1212m -> Behringer B2031A monitors). I hope this isn't a TOS #8 violation. I've been trying to sell my friends on trying it out. I'm not using the resampling or the dithering... I realize some of the issues with seeking are intractable right now - what else is on the development horizon?
Thanks a lot, sboistan.
what else is on the development horizon?
Currently I don't see any urgent need to change something. However, there are some ideas:
- Make the "hidden" feature described above official, i.e. allow for pseudo-tagging via a CSV file. Before making this feature an official one there are some refinements needed allowing more flexibility for the user.
- Allow for more DSP effects offered by SoX, e.g. the contrast, compand and mcompand effects (cf. http://sox.sourceforge.net/sox.html) (http://sox.sourceforge.net/sox.html).
What would you like to see?
Both of those features would be great. I haven't tried the CSV pseudo-tagging yet (I'm willing to do it, but would appreciate an easier technique for tagging), but I have an archive of MKV'd 2-channel music dvds that I'd love to be able to replaygain and play using FFsox output. For low-volume listening, I've been using a multiband dynamic range compressor called Breakaway Pipeline (16 bit input/output only) and would be very interested in trying mcompand.
2 minor issues: 1. I can't get it to see RG values with any aac file. Ogg and Flac are fine. 2. With a number of different file types, if I right click for file info in Winamp, it lists FFmpeg as the decoder, while it says FFsox is being used in the albumart playback panel (big bento skin). Has the file been opened by ffsox or ffmpeg?
1. I can't get it to see RG values with any aac file.
How do you RG AAC?
2. With a number of different file types, if I right click for file info in Winamp, it lists FFmpeg as the decoder, while it says FFsox is being used in the albumart playback panel (big bento skin). Has the file been opened by ffsox or ffmpeg?
Of course it's the FFSoX plug-in. Internally FFSoX may choose the SoX or the FFmpeg library for opening and decoding the file. That's the information you get from the info dialog. It's just another example for that the FFSoX plug-in doesn't re-invent the wheel but instead uses the underlying libraries.
Sound processing is done by SoX in any case.
How do you RG AAC?
http://altosdesign.com/aacgain/ (http://altosdesign.com/aacgain/)
How do you RG AAC?
Sorry, I meant replaygained aac in mp4/m4a container (replaygaining done by Foobar2000). I'm not sure if I want to resort to AACGain.
Of course it's the FFSoX plug-in. Internally FFSoX may choose the SoX or the FFmpeg library for opening and decoding the file. That's the information you get from the info dialog. It's just another example for that the FFSoX plug-in doesn't re-invent the wheel but instead uses the underlying libraries.
Sound processing is done by SoX in any case.
Ok, that's what I was trying to ask - if Sox was doing the sound processing. Thanks.
1. I can't get it to see RG values with any aac file.
In order to get an idea I did the following:
- Created an AAC file using NeroAacEnc:
D:\>neroaacenc -if C:\WINDOWS\Media\RINGIN.WAV -of RINGIN.M4A
*************************************************************
* *
* Nero AAC Encoder *
* Copyright 2009 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Feb 18 2010 *
* Package version: 1.5.4.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 0 seconds...
D:\>_
- Calculated RG values using WaveGain:
wavegain -a C:\WINDOWS\Media\RINGIN.WAV
Analyzing...
Gain | Peak | Scale | New Peak |Left DC|Right DC| Track
| | | |Offset | Offset |
--------------------------------------------------------------
-10.04 dB | 23039 | 0.31 | 7252 | 34 | 0 | C:\WINDOWS\Media\RINGIN.WAV
Recommended Album Gain: -10.04 dB Scale: 0.3148
WaveGain Processing completed normally
D:\>_
- Tagged the M4A file accordingly using NeroAacTag (please note the switch -meta-user instead of -meta, i.e. non-standard meta data):
D:\>neroaactag RINGIN.M4A "-meta-user:replaygain_track_gain=-10.04" "-meta-user:replaygain_album_gain=-10.04"
*************************************************************
* *
* Nero MPEG-4 Audio Tagger *
* Copyright 2009 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Dec 17 2009 *
* Package version: 1.5.1.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processing file: "RINGIN.M4A"
Updating MP4 file...
File updated successfully.
D:\>_
- Listed the M4A's metadata using NeroAacTag:
D:\>neroaactag RINGIN.M4A -list-meta
*************************************************************
* *
* Nero MPEG-4 Audio Tagger *
* Copyright 2009 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Dec 17 2009 *
* Package version: 1.5.1.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processing file: "RINGIN.M4A"
Metadata list:
cdec = ndaudio 1.5.4.0 / -q 0.50
itunsmpb = 00000000 00000A40 000002C3 00000000000026FD 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
replaygain_album_gain = -10.04
replaygain_track_gain = -10.04
tool = Nero AAC codec / 1.5.4.0
End of metadata.
No changes made to the file.
D:\>_
These tags are honored by WA's build-in AAC decoder but not by the FFSoX plug-in. Propably the reason is the following. - Listed the M4A's metadata using FFmpeg:
D:\>ffmpeg -i RINGIN.M4A
FFmpeg version SVN-r24743-snapshot, Copyright (c) 2000-2010 the FFmpeg developers
built on Aug 13 2010 08:20:05 with gcc 4.5.0
configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-w32threads --enable-
runtime-cpudetect --enable-memalign-hack
libavutil 50.23. 0 / 50.23. 0
libavcore 0. 3. 0 / 0. 3. 0
libavcodec 52.84. 3 / 52.84. 3
libavformat 52.78. 1 / 52.78. 1
libavdevice 52. 2. 1 / 52. 2. 1
libavfilter 1.31. 0 / 1.31. 0
libswscale 0.11. 0 / 0.11. 0
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RINGIN.M4A':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: M4A mp42isom
encoder : Nero AAC codec / 1.5.4.0
Duration: 00:00:01.20, start: 0.000000, bitrate: 27 kb/s
Chapter #0.0: start 0.238005, end 1.207438
Metadata:
title :
Stream #0.0(und): Audio: aac, 11025 Hz, mono, s16, 16 kb/s
At least one output file must be specified
D:\>_
It looks like FFmpeg is not reading non-standard meta data from M4A. Someone should provide FFmpeg with an according patch ...
I should set the psudo-tagging feature of the FFSoX plug-in to first priority in order to work around missing FFmpeg features.
v0.4.5 releasedWhat's new?
- Fixed mapping tags (under certain circumstances "Album Artist" where not properly mapped or could mask "Album").
- Fixed playing mono.
- Changed suggestion (http://in-ffsox.sourceforge.net/#multiple-integer-suggestion) when to use "multiple integer" mode for up-sampling.
For details go here (http://in-ffsox.sourceforge.net/).
For download go here (http://sourceforge.net/projects/in-ffsox/files/).
v0.4.6 released[blockquote]
http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Support for mixed ReplayGain (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification) and EBU R128 (http://tech.ebu.ch/loudness) playback added:
(http://home.snafu.de/pbelkner/upload/110115/01/preferences-r128.png)
(http://home.snafu.de/pbelkner/upload/110115/01/preferences-rg.png)
- The configuration allows for defining a relative gain between the two standards, typically about 5 dB. The relative gain can be adjusted according to the user's preferences.
- It is possible to switch between the normative loudness of both approaches, -23 LUFS and 83 dB, respectively. The respective gains are adapted automatically.
- If the "Write Comment" is checked RG respective information is written into the File Info's comment field
(http://home.snafu.de/pbelkner/upload/110115/01/file_info.jpg)
- Depending on whether the effective gain resulting from RG and pre-amp is an amplification or an attenuation up-sampling is done first or last in the processing chain, respectively, in order to avoid clipping.
v0.4.6.1 released[blockquote]
http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Fixed a minor flaw in synchronizing the configuration's RG sliders
FFmpeg has "bumped" their DLLs:
- avutil-50.dll => avutil-51.dll
- avcodec-52.dll => avcodec-53.dll
- avformat-52.dll => avformat-53.dll
- avcore-0.dll dropped
Version 0.4.6.4 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Compatible to the latest (bumped) FFmpeg versions.
For upgrading to full FFmpeg (needed for playback of e.g. MP3, H264 and many other codecs and formats) get the FFmpeg DLLs from the latest shared builds
- at Zeranoe: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/), or
- at Bizzeh: http://www.bizzeh.com/ffmpeg/free/shared/ (http://www.bizzeh.com/ffmpeg/free/shared/).
The decoder for mp3 and ac3 files seems to be locked to libavcodec (16 bit, float/16 bit in the case of ac3 files) in these newer versions. I suppose it shouldn't make much of a difference perceptually...
The decoder for mp3 and ac3 files seems to be locked to libavcodec (16 bit, float/16 bit in the case of ac3 files) in these newer versions. I suppose it shouldn't make much of a difference perceptually...
This is by intention because it is the correct behaviour in case "libmad.dll" and "liba52.dll" are not available.
Hopefully the next version will make the 32 bit float decoders from libavcodec available.
Version 0.4.6.5 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Enables 32 bit float format for decoding e.g. MP3, AC3 and other lossy audio codecs.
- Enables (and requires) usage of FFmpeg's "swscale-2.dll", i.e. compatible to the latest FFmpeg versions. For upgrading to full FFmpeg (needed for playback of e.g. MP3, H264 and many other codecs and formats) get the FFmpeg DLLs from the latest shared builds at Zeranoe: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/).
Version 0.4.6.6 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Provided the option "Force Seek" in order to allow for seeking without any test whether seeking is supported by a format or not.
NOTE: If checked and a particular format doesn't support seeking the behavior is undefined. - Provided the option "Prefer Float" for switching on/off 32 bit floating point decoders for lossy codecs.
Version 0.4.6.7 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Unicode support for file and directory names.
- Unicode support for metadata.
- Option "SoX Decoder" removed.
Too bad that tags and RG for Musepack still don't work...
Version 0.4.7 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- According to FFmpeg.org (http://ffmpeg.org/): FFmpeg development has gone into OVERDRIVE. As a consequence the FFSoX Player plugin wasn't compiling any longer using the latest FFmpeg versions. This release ports R128GAIN to the latest FFmpeg API.
- Video synchronization has been greatly improved by replacing heuristics with a call to av_opt_ptr(avcodec_get_frame_class(), frame, "best_effort_timestamp");
- This release requires "avformat-54.dll" and "avcodec-54.dll", and is now again in line with the latest FFmpeg builds from http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/).
Version 0.4.8 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
- Upgraded to new SoX 14.4.0 (http://sourceforge.net/mailarchive/forum.php?thread_name=20120304232814.GA30088%40eeet101mt&forum_name=sox-devel).
- Restructured build process for the tool chain.
hi
great plugin
my problem mp3 file prefer float codec uncheck option
ı see file info
16 input = 16 output no problem sound very good..
check prefer float
32bit input= output 16 bit?? output not 32 bit sometimes error decode display and poor quality sound..
sorry my bad english..
hi
great plugin
my problem mp3 file prefer float codec uncheck option
? see file info
16 input = 16 output no problem sound very good..
check prefer float
32bit input= output 16 bit?? output not 32 bit sometimes error decode display and poor quality sound..
sorry my bad english..
The decoder is one thing. The other is how to route the decoded sound to the DAC (sound card). If there are just 16 bit available, then that's it. If you have 24 bit available you should configure FFSoX as well as WA accordingly, cf. 9. and 11. from http://in-ffsox.sourceforge.net/#additional_setup (http://in-ffsox.sourceforge.net/#additional_setup).
Regards, Peter
hi
great plugin
my problem mp3 file prefer float codec uncheck option
? see file info
16 input = 16 output no problem sound very good..
check prefer float
32bit input= output 16 bit?? output not 32 bit sometimes error decode display and poor quality sound..
sorry my bad english..
The decoder is one thing. The other is how to route the decoded sound to the DAC (sound card). If there are just 16 bit available, then that's it. If you have 24 bit available you should configure FFSoX as well as WA accordingly, cf. 9. and 11. from http://in-ffsox.sourceforge.net/#additional_setup (http://in-ffsox.sourceforge.net/#additional_setup).
Regards, Peter
ok thanks..closed mp3 decoder option(liblav) .what open mp3 decoder option(libmad etc)
ok thanks..closed mp3 decoder option(liblav) .what open mp3 decoder option(libmad etc)
I'm not certain on what you are asking about. "libmad" as well as "liba52" are not an option any longer because they are not integrating smoothly with FFmpeg any longer since some internal FFmpeg changes by the end of December 2011. On the other hand FFmpeg's own MP3 and AC3 decoders (from "libavcodec") are perfect, especially in 32 bit float mode.
hi
ı try aimp http://aimp.ru/ (http://aimp.ru/) (asio volume bar option,less ram cpu ıd3 tag etc)
4.6.6 works well..
4.8 dont work...
fixing? compatible aimp?
hi
? try aimp http://aimp.ru/ (http://aimp.ru/) (asio volume bar option,less ram cpu ?d3 tag etc)
4.6.6 works well..
4.8 dont work...
fixing? compatible aimp?
As long as the plug-in properly works in Winamp, there is nothing the author can (and should) do about it. If AIMP is supposed to be compatible with all Winamp plug-ins, but is not, then report it to the respective developers.
- Allow for more DSP effects offered by SoX, e.g. the contrast, compand and mcompand effects (cf. http://sox.sourceforge.net/sox.html) (http://sox.sourceforge.net/sox.html).
Would be nice to have something as simple and powerful as a user defined SoX command line. E.g. something like:
sox -p -p rate -h 96kwhere "
rate -h 96k" can be any SoX effect chain.
- Allow for more DSP effects offered by SoX, e.g. the contrast, compand and mcompand effects (cf. http://sox.sourceforge.net/sox.html) (http://sox.sourceforge.net/sox.html).
Would be nice to have something as simple and powerful as a user defined SoX command line. E.g. something like:
sox -p -p rate -h 96k
where "rate -h 96k" can be any SoX effect chain.
This would be of great value to the plugin because it would allow users to have full access to SoX, and that's why I like the idea very much. Unfortunately there's no "out of the box" parser for the SoX command line, and I have write one at least for the effects chain syntax.
Currently I have the following plans for the FFSoX player plugin:
- Merge the code bases from FFSoX player and R128GAIN (http://r128gain.sourceforge.net/).
- Integrate the R128GAIN loudness scanner into FFSoX player.
- Because R128GAIN alreaday writes tags, use this functionality for making it possible to write tags with the FFSoX player plugin.
I'm considering to add your idea to the list. But I have to admit that currently I'm in a process of re-writing R128GAIN which is a prerequisite to step 1.
I see... not as easy as I thought. Anyway, thanks for considering. :-)
This would be of great value to the plugin because it would allow users to have full access to SoX, and that's why I like the idea very much. Unfortunately there's no "out of the box" parser for the SoX command line, and I have write one at least for the effects chain syntax.
You’d only need to split the line wherever the name of an effect appears. All other parsing is done by the effects themselves.
Thanks for this great plugin. To me, it sounds better than the default Winamp5lite FLAC decoder. But I may be mistaken as the Foobar2000 FAQ says that there's no difference between almost all the modern music players (http://www.foobar2000.org/FAQ#other_questions /sound better). Anyway, I just use the default FFSox configuration and I'm happy with it for now. I just really hope that some day, the seek forward/backward (according to player's song progress button) feature will be available. I've used SoX on Linux too and as far as I can remember it's not able to seek while playing FLAC files. It would be really great if one could do that. Please basically explain to me why this feature isn't built-in the SoX player and why it's not possible - or recommended - to enable it. MPlayer, which is also a great FLAC decoder, is able to seek backward and forward. On Windows, though, I prefer to use Winamp for plugins.
Thanks.
Thanks for this great plugin. To me, it sounds better than the default Winamp5lite FLAC decoder.
Thank you
Edit: Of course, this is not due to the FLAC decoder but to the processing chain delivering the decoded audio to your sound card. Each FLAC decoder will produce the same audio stream because FLAC is a lossless format.
But I may be mistaken as the Foobar2000 FAQ says that there's no difference between almost all the modern music players (http://www.foobar2000.org/FAQ#other_questions /sound better).
Cf. my motto below and trust your ears. I've figured this out wasting about ten years unsuccessfully following other people's advise.
Please basically explain to me why this feature isn't built-in the SoX player and why it's not possible - or recommended - to enable it.
Please double check whether you have enabled seeking:
(http://in-ffsox.sourceforge.net/upload/120928/properties.jpg)
That you have to manually enable seeking dates back to the times when seeking was not reliable implemented in FFmpeg. Meanwhile seeking in FFmpeg can be considered stable and I should remove the option with the next release.
You should also double check whether you have enabled "prefer float". This option means that the 32 bit float decoders are chosen for lossy codecs instead of 16 bit integer.
But I may be mistaken as the Foobar2000 FAQ says that there's no difference between almost all the modern music players (http://www.foobar2000.org/FAQ#other_questions /sound better).
Cf. my motto below and trust your ears. I've figured this out wasting about ten years unsuccessfully following other people's advise.
Elge's post is subject to TOS #8 and will not get a pass.
That you've piled on in the way that you did is pretty disconcerting, especially since you've never once provided any evidence to back TOS8 violations of your own and apparently continue to think you are somehow immune to expectation bias, despite insisting that you only listen with your "ears" (which is the true historical basis for the defiant "motto" in your signature).
Version 0.4.9-2 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.4/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.4/)[/blockquote]What's new?
- Made it compatible with the latest FFmpeg (http://ffmpeg.org/) version.
- Requires "avutil-52.dll".
Monkey's Audio APE files stutter by using FFSoX with Zeranoe ffmpeg (since ffmpeg-20121003-git build)
I use ffmpeg daily builds from Zeranoe in combination with FFSoX Player for Winamp to play all my music files
(AAC;AIF;AIFF;APE;FLAC;M4A;M4P;MP3;MPC;OGG;SHN;WAV;WMA;WV)
Until Zeranoe build ffmpeg-20120927-git-13f0cd6-win32-shared from September 27th
everything worked fine and smooth, including the decoding of Ape files.
Since Zeranoe build ffmpeg-20121003-git-df82454-win32-shared.7z from Oct 3rd
Monkey's Audio APE files give stuttering sound and produce various artificial noice effects.
Later builds didn't resolve the problem. Neither the newest ffsox player version 0.4.9.3, nor the latest Zeranoe build from Nov. 5th
resolved this annoyance.
I started a topic at the Zenaroe FFMPEG forum, see: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=3&t=799 (http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=3&t=799)
the sample.ape from my post there plays correctly with ffplay from the command line in all different ffmpeg builds.
Is it something within the Sox part of FFSoX player?
And can it be resolved please?
Greetings,
Smeekeven[size="4"][/size]
Since Zeranoe build ffmpeg-20121003-git-df82454-win32-shared.7z from Oct 3rd
Monkey's Audio APE files give stuttering sound and produce various artificial noice effects.
As is seems they've changed several of the FFmpeg audio decoders to produce planar output instead of interleaved.
Planar audio was not supported by the FFSoX Player so far. The new 0.4.9-4 version should fix this:
[blockquote]http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.4/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.4/)[/blockquote]
APE stuttering problems SOLVED in FFSoX Player 0.4.9-4
Many thanks to you pbelkner for amazingly quick response and efficiënt solution to the Monkey's Audio Ape decoding problems.
I really like your FFSoX Player plugin.
Since I use it to decode and upsample all of my audio formats
(AAC;AIF;AIFF;APE;FLAC;M4A;M4P;MP3;MPC;OGG;SHN;WAV;WMA;WV;)
it make all other input plugins in Winamp obsolete*.
(*The only exception to this rule is the Playlist Separator in_text.dll input plugin by DrO
http://www.nunzioweb.com/daz/plsp.html (http://www.nunzioweb.com/daz/plsp.html), but that's outside the scope of audio decoding ....)
With every new build of Zeranoe ffmpeg (http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D)
i will update the avCodec-dll, avFormat-.dll, avUtil-.dll, swScale-.dll in the /Winamp/Plugins/in_ffsox directory
By the way what is planar output versus interleaved?
Cheers!
smeekeven
Since I use it to decode and upsample all of my audio formats
(AAC;AIF;AIFF;APE;FLAC;M4A;M4P;MP3;MPC;OGG;SHN;WAV;WMA;WV;)
it make all other input plugins in Winamp obsolete*.
You may consider including "FLV;MP4" as well. These are the usual extensions for video clips, e.g. from Youtube. This way you can seamlessly include them into your playlist.
By the way what is planar output versus interleaved?
In FFmpeg the term "planar" refers to how an audio buffer is organized:
- planar: There are separate buffers for each channel in parallel.
- interleaved: There is just one buffer filled with sequences of samples from each channel.
Hi,
In my first post here I would like to thank you for this excelent project! I've replaced all audio input plugins with FFSoX and full version of ffmpeg.
However, with Zeranoe FFmpeg v20121105, ogg do not play properly (same problem as fixed APE).
Keep your great work!
Hi,
In my first post here I would like to thank you for this excelent project! I've replaced all audio input plugins with FFSoX and full version of ffmpeg.
However, with Zeranoe FFmpeg v20121105, ogg do not play properly (same problem as fixed APE).
Keep your great work!
Thank you for the report, and I can reproduce it. Unfortunately I don't have a solution yet. FFmpeg's OGG decoder claims to be AV_SAMPLE_FMT_FLT, i.e. interleaved, the same as e.g. AAC and AC3. Other then OGG, decoded AAC and AC3 work fine.
It would be very nice if you can specify decoder libraries e.g. for ogg - libogg / libvorbis, for mp3 - libmad etc. without passing it to ffmpeg. Ffmpeg, for example, don't support MP3 freeformat like 640 kbps whil libmad supports it. But its only a dream now
with Zeranoe FFmpeg v20121105, ogg do not play properly (same problem as fixed APE).
It's not exactly the same. For what ever reason the FFmpeg method
av_get_bytes_per_sample() nowadays gives unexpected results in case of the OGG codec (at least to me). I've changed
in_ffsox in order to avoid this particular method at all and released
version 0.4.9-5:[blockquote]
https://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.4/ (https://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.4/)[/blockquote]
v0.5.0 released[blockquote]
http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.5/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.5/)[/blockquote]What's new?
- Allow for applying intermediate replay gain values between album gain (0%) and track gain (100%):
[/quote]
Rewritten and reactivated the FFmpeg adapters for
"libmad.dll" and
"liba52.dll".
[li]Fixed a memory leak.[/li][/list]
Version 0.6.0 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.6/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.6/)[/blockquote]What's new?
- Provided the Secret Rabbit Code (SRC) (http://www.mega-nerd.com/SRC/) resampler as an alternative to the SoX resampler.
- Please note that the SRC resampler takes a lot of CPU compared to the SoX resampler:
- SRC (best):
[blockquote](http://in-ffsox.sourceforge.net/images/0.6.0/ressources-src-best.png)[/blockquote] - SoX (very high):
[blockquote](http://in-ffsox.sourceforge.net/images/0.6.0/ressources-sox-very-high.png)
[/blockquote] - SRC (medium):
[blockquote](http://in-ffsox.sourceforge.net/images/0.6.0/ressources-src-medium.png)
[/blockquote]
- Please note that the SRC resampler takes a lot of CPU compared to the SoX resampler:
So that's the down-side—is there an up-side?
is there an up-side?
Yes, of course! Unfortunately I can't tell you 'cause probably it's subject to TOS #8
is there an up-side?
Yes, of course! Unfortunately I can't tell you 'cause probably it's subject to TOS #8
Sounds like BS! How can you claim "Of course" and subject to TOS #8 in one sentense? If it is "Of course" it should be simple to demonstrate.
I think it's a good idea, thought I think there are too many choices. 25%, 50% and 75% should be adequate, 20% steps will definitely be adequate.
Version 0.6.1 released:
[blockquote]Home: http://in-ffsox.sourceforge.net/ (http://in-ffsox.sourceforge.net/)
Download: http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.6/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.6/)[/blockquote]What's new?- Provided a switch to enable the "steep filter" for the SoX resampler.
- Disabled editing all drop down boxes except "replay gain mode" and "phase response" for the SoX resampler.
- Accepted input for the "replay gain mode" is 0..100.
- The RG mode drop down list just contains the values as proposed by greynol:
(http://in-ffsox.sourceforge.net/images/0.6.1/rg.png) - Accepted input for the "phase response" is 0..100.
Problems with playback MPC (Musepack) files
Thanks for the steep development of your plugin.
In addition to the problems with APE and OGG playback, some weeks ago (see posts by Polarus and myself),
there is a similar problem with stuttering sound in MPC (musepack) files.
I hope you can resolve this the same way you did to the APE and OGG decoding.
Thanks very much again and keep up the good work.
By the way: do you recommend the use of the steep filter option? and why?
This is a very impressive piece of TOS-8 skirting: the posts here omit all mentions of sound quality, but the plugin doesn't seem to make much sense unless it's meant to influence SQ...
By the way: do you recommend the use of the steep filter option? and why?
This is a very impressive piece of TOS-8 skirting: the posts here omit all mentions of sound quality, but the plugin doesn't seem to make much sense unless it's meant to influence SQ...
Currently I prefer the following set-up:
- Audio input tagged (normalized) according to EBU R128 (http://tech.ebu.ch/loudness) (if you're located in Northern America you should prefer ATSC A/85 (http://www.atsc.org/cms/index.php/standards/recommended-practices/185-a85-techniques-for-establishing-and-maintaining-audio-loudness-for-digital-television) instead) using "r128gain" (http://r128gain.sourceforge.net/).
- Using a DAC capable of ASIO, 24 bits, and 192 kHz.
- WA configured to allow for 24 bit output:
(http://in-ffsox.sourceforge.net/images/0.6.1/wa-playback.png)
- WA output via "out_asio" by Otachan (http://otachan.com/out_asio%28dll%29.html):
(http://in-ffsox.sourceforge.net/images/0.6.1/wa-output.png)
- WA input via the FFSoX Player "in_ffsox" (http://in-ffsox.sourceforge.net/) with
- up-sampling enabled to 192 kHz,
- using the SoX resampler with "high quality" and "steep filter", and
- dithering with noise shaping:
(http://in-ffsox.sourceforge.net/images/0.6.1/wa-sox.png) - FFSoX's "replay gain mode" set to 50%:(http://in-ffsox.sourceforge.net/images/0.6.1/rg.png)
Edit: Regarding the "steep filter" you may refer to SoX's resampler's "-s" option: http://sox.sourceforge.net/SoX/Resampling (http://sox.sourceforge.net/SoX/Resampling).
AFAICT none of those preferences have any bearing on audible sound quality that you will be able to demonstrate through objective means. Prove that I'm wrong.
By the way: do you recommend the use of the steep filter option? and why?
Don't hold your breath waiting for a tangibly meaningful answer to this second question.
Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.
Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.
That's a perfect example of a Straw man (http://en.wikipedia.org/wiki/Straw_man): Besides the argument may be true w.r.t. to the automatic dithering feature of the SoX command line tool, it is not true w.r.t to the FFSoX plug-in. If the respective check box is checked the dithering effect is added to the effects chain, otherwise not (regardless whether this is useful or not). There's no automatic dithering in FFSoX.
Edit: If the emphasis is on "noise shaped" than the argument seems to be valid. The following is from SoX's "dither.c":
static const filter_t filters[] = {
{44100, fir, 5, 210, lip44, Shape_lipshitz},
{46000, fir, 9, 276, fwe44, Shape_f_weighted},
{46000, fir, 9, 160, mew44, Shape_modified_e_weighted},
{46000, fir, 9, 321, iew44, Shape_improved_e_weighted},
{48000, iir, 4, 220, ges48, Shape_gesemann},
{44100, iir, 4, 230, ges44, Shape_gesemann},
{48000, fir, 16, 301, shi48, Shape_shibata},
{44100, fir, 20, 333, shi44, Shape_shibata},
{37800, fir, 16, 240, shi38, Shape_shibata},
{32000, fir, 20, 240/*TBD*/, shi32, Shape_shibata},
{22050, fir, 20, 240/*TBD*/, shi22, Shape_shibata},
{16000, fir, 20, 240/*TBD*/, shi16, Shape_shibata},
{11025, fir, 20, 240/*TBD*/, shi11, Shape_shibata},
{ 8000, fir, 20, 240/*TBD*/, shi08, Shape_shibata},
{48000, fir, 16, 250, shl48, Shape_low_shibata},
{44100, fir, 15, 250, shl44, Shape_low_shibata},
{44100, fir, 20, 383, shh44, Shape_high_shibata},
{ 0, fir, 0, 0, NULL, Shape_none},
};
If a particular sample rate doesn't fit into the map the request for noise shaping is ignored:
for (f = filters; f->len && (f->name != p->filter_name || fabs(effp->in_signal.rate - f->rate) / f->rate > .05); ++f); /* 5% leeway on frequency */
if (!f->len) {
p->alt_tpdf |= effp->in_signal.rate >= 22050;
if (!effp->flow)
lsx_warn("no `%s' filter is available for rate %g; using %s TPDF",
lsx_find_enum_value(p->filter_name, filter_names)->text,
effp->in_signal.rate, p->alt_tpdf? "sloped" : "plain");
}
AFAICT none of those preferences have any bearing on audible sound quality that you will be able to demonstrate through objective means. Prove that I'm wrong.
Steep filter here gives 99% instead of 95% passband, so compare (on unix):
play -r 16k -n synth 4 sin 7920 rate 48k
play -r 16k -n synth 4 sin 7920 rate -s 48k
Difference is night and day. Though with a typical ADC instead of a synth'd signal, there's probably no useful (unaliased) content that high up.
I didn't think qualifications against synthesized signals would be necessary. I suppose I should also mention that I'm not interested in cranking the volume on fade-outs too.
Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.
That's a perfect example of a Straw man (http://en.wikipedia.org/wiki/Straw_man): Besides the argument may be true w.r.t. to the automatic dithering feature of the SoX command line tool, it is not true w.r.t to the FFSoX plug-in. If the respective check box is checked the dithering effect is added to the effects chain, otherwise not (regardless whether this is useful or not). There's no automatic dithering in FFSoX.
Edit: If the pronunciation is on "noise shaped" than the argument seems to be valid. The following is from SoX's "dither.c":
Straw man? Pronunciation? Huh?
Pronunciation? Huh?
Many thanks for the hint. I've corrected it.
Still i feel insulted by your Straw Man argument. You are the person explicitly recommending 192kHz upsampling with emphasis on Noise Shaping while sox doesn´t.
You are the person explicitly recommending 192kHz up-sampling with emphasis on Noise Shaping while sox doesn't.
- Put into general terms, the recommendation is to set the sample rate to the maximum sample rate supported by the DAC. Any other setting makes no sense because in such a case we can assume the DAC to up-sample a second time. My DAC supports 192 kHz, hence the preference.
- AFAIK there are still a lot of DACs out there supporting just 48 kHz. In such a case it perfectly makes sense to choose the "noise shaping" option. For a general recommendation I see no need to dive into a discussion on whether SoX is supporting that option for a particular sample rate or not, because in case it is not supported it is simply ignored.
@pbelkner: To put it on perspective, i'll give my point of view of in_ffsox before comenting on these last posts.
When you announced in_ffsox, I didn't see the need for it at all (most, if not all of the formats that the plugin provided, were already supported, and there wasn't a reason to think that the quality was suffering). The part about resampling could be and addition, (because a resampler as a DSP in winamp is problematic), but not a "must have" feature.
Now, onto the real subject:
The necessity of having a resampler between the source format, and the soundcard happens only when the soundcard (or its drivers) apply a bad quality one, and only then, if you can provide a better one. Since you're talking about soundcards supporting 192Khz, the question arises by itself.
It also makes me wonder the usage of a steeper filter cutoff than the default. The origin of higher sampling rates, and especifically, of upsampling DACs was precisely the ability to use a softer cutoff (easier to implement, and less ripple).
Now, dithering and noise shaping.
Dithering applies to bit depth, and noise shaping is dependant on sample rate. Using dithering at 24bits for playback is one of those things that can directly be considered nonsense. No hardware is able to play 24bits, so how can the last bit truncation matter? Sometimes it has been said (see wiki (http://wiki.hydrogenaudio.org/index.php?title=Dither)) that even dithering at 16bits is unneeded when the source is noisy, like a tape recording.
So if dithering is not necessary (like I'm saying above), shaping the result doesn't matter. It's true that being a high sample rate, it can shift most of the noise outside of the audible range (higher frequency), but in practice, it already is (below the noise floor).
When you announced in_ffsox, I didn't see the need for it at all (most, if not all of the formats that the plugin provided, were already supported
This may be true for audio formats but by no means this is true for video formats. I'm not aware of any other player supporting ReplayGain for video formats. To me, RG for video formats is the outstanding feature of "in_ffsox" and the lack of it in existing players was the initial driving force for developing the plug-in.
I didn't think qualifications against synthesized signals would be necessary.
The synth'd signal is just a sine wave—it could have been captured using an ADC with a steep filter.
Ok, I didn't think about it.
How is the replaygain calculated, and how is it stored? (Directly from Winamp? I ask because i didn't saw it in the plugin's sourceforge page, and i could only find a tool called ffmpeg-replaygain, not updated in two years)
On the other hand, the wording in the "Objectives" section (and part of others) in that page wouldn't probably pass HydrogenAudio's standards.
(Also note that I would use winamp kernel streaming (http://www.stevenmonks.pwp.blueyonder.co.uk/ks_plugin/plugin.html) plugin, if the soundcard needs ASIO4ALL to have ASIO capabilities).
How is the replaygain calculated, and how is it stored? (Directly from Winamp? I ask because i didn't saw it in the plugin's sourceforge page, and i could only find a tool called ffmpeg-replaygain, not updated in two years)
You may use "r128gain" (http://r128gain.sourceforge.net/) (it's mentioned on top of the SF page).
Only a few video formats can store RG tags, e.g. FLV and MKV. For the others, e.g. VOB, AVI, MP4, you should use the MKV format option from "r128gain". This will wrap the video and audio streams taken from the input into a RG tagged MKV container you may playback with "in_ffsox".
The synth'd signal is just a sine wave—it could have been captured using an ADC with a steep filter.
Synthesized...as opposed to an actual piece of music.
Either way, thanks for providing something the author seems either unwilling or unable to do. So based on your expertise on the matter, are his veiled claims of audible superiority justified?
If source and destination rates are both >= 44100, then SoX's default transition-band preserves the entire audio band (i.e. to 20kHz), so there's no benefit in a steeper filter. If at least one of the rates is < 44100, then the default transition-band lies at least partly within the audio band. If your ADC (or DAC or both) used with this audio has a steep filter, then you might as well preserve the extra bandwidth this gives by using a steep resampling filter. I wouldn't be surprised if some people could ABX the difference this gives, on some music.
However, are ADCs/DACs with steep filters and at < 44100Hz sample-rate much used in practice? Not as far as I know. E.g. the AES (and ITU) recommendation for "high quality" (as opposed to "studio quality") audio is sampled at 32kHz but the nominal passband is 15kHz (I assume 3dB point) so audio captured according to this spec. and subsequently upsampled would not require a steep filter.
Hi Peter Belkner,
You know I'm a dedicated user of your plugin, I love it.
With this month additions of the zeranoe ffmpeg daily builds things are broken ....
The stuttering sounds happen all over the playlist: MP3, MPC and APE are all affected.
Only FLAC seems to decode properly.
Can you please take a look at this?
Thanks!
Problems with decoding MP3, APE and MPC files since version 0.4.9.5
Happy Newyear!
I just found out that the new Zeranoe ffmpeg builds (latest from 20130103) are ok with in_ffsox up to version 0.4.9.4
All file formats (i.e. FLAC, MP3 but also APE and MPC) are decoding perfectly normal.
Since version 0.4.9.5 up to 0.6.1 there are errors ("stuttering") with APE and MPC and even MP3's
Hope this can be resolved in the next build of in_ffsox
Thanks in advance!
Happy Newyear!
Happy new year too!
Since version 0.4.9.5 up to 0.6.1 there are errors ("stuttering") with APE and MPC and even MP3's
Unfortunately I'm not able to reproduce this. But I've changed something with the planar representation anyway and have uploaded a new version. Hope this helps.
http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.6/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox/in_ffsox-0.6/)
in_ffsox-0.6.2-ffmpeg works perfectly !
PBelkner did a great job by releasing a major update of the in_ffsox plugin.
His tweaking of the planar representation makes that all audio formats can be played flawlessly through the ffmpeg filters.
There is no more "stuttering" noise that was obvious when decoding mp3, mpc, ape, wv and shn files in versions prior to this release.
I use ffmpeg daily builds from Zeranoe in combination with FFSoX Player for Winamp to play all my music files
(AAC;AIF;AIFF;APE;FLAC;M4A;M4P;MP3;MPC;OGG;SHN;WAV;WMA;WV)
ffmpeg builds can be found at:
http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D (http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D)
Just copy the avcodec-54.dll, avformat-54.dll, avutil-52.dll and swscale-2.dll over the existing ones in
\winamp\plugins\in_ffsox directory
Cheers!
New avcodec-55.dll and avformat-55.dll Zeranoe builds
Hi Peter,
avcodec-55.dll and avformat-55.dll are updated versions of avcodec-54.dll and avformat-54.dll and new in
ffmpeg-20130314-git-9efcfbe-win32-shared Zeranoe daily builds of ffmpeg
http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D (http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D)
Can you please adapt the ffsox player plugin to work with this new versions?
Thanks in advance.
Greetings,
Smeekeven.
New avcodec-55.dll and avformat-55.dll Zeranoe builds
Can you please adapt the ffsox player plugin to work with this new versions?
I've uploaded in_ffsox-0.6.3.
Thank you for your support.
Regards, Peter
Peter did end up toning down the docs to just say what the plug-in does and how to configure it. I think that's for the best, but if anything, it's a little too terse now; you have to infer what most of the features are by looking at the configuration info. Here is what I would say about it, if I were the developer:
[blockquote]FFSoX Player is an input plug-in for Winamp that supports reading audio & video files. It tailors the audio to specific characteristics (bit depth, sample rate, dither, and volume level), for the potential benefit of the rest of the output chain (i.e., the DSP plug-ins, the output plug-in, Windows audio APIs, and your audio hardware). The plug-in itself chains FFmpeg for file reading; an audio pre-amp for an initial volume change; SoX for resampling and dithering; and a ReplayGain processor for final volume change.
Features:
- As is common for input plug-ins, you can choose exactly what file types it applies to (via a list of file name extensions).
- It potentially reads anything FFmpeg can, including video files. Support for some formats may require replacing FFmpeg DLLs after installation, however.
- When reading video files, the video can be shown or ignored. If ignored, the enabled visualization (if any) can be shown instead.
- Audio and video buffering are both configurable.
- Audio output bit depth can be 16 or 24.
- All internal audio processing is done in 32-bit floating-point.
- The pre-amp can modify the volume by ±12.0 dB.
- SoX processing (resampling and dither) can be enabled always, never, or only when needed.
- Resampling quality can be reduced for speed (quality choices are Quick, Low, Medium, High, Very High).
- The desired output sample rate can be an absolute requirement (forcing up- or down-sampling of any other input rate) or it can be a minimum acceptable rate (forcing up-sampling only).
- The actual output sample rate can be forced to be an integer multiple of the input rate; desired rate will be considered a minimum acceptable multiple.
- Many types of dither are available.
- The ReplayGain processor has a slider allowing album and track gain to be mixed in any ratio.
- Pre-amp & ReplayGain diagnostic info can optionally replace comment tag data in the File Info dialog (Alt+3).
- A separate group of all of the audio settings is available for use by Winamp's Format Converter.
[/blockquote]
The TOS#8-violating theory behind its development notwithstanding, it turns out that the plug-in does solve a very real and obvious sound-quality problem for me.
The SHOUTcast DSP for Winamp does some wickedly poor-quality resampling if its input isn't at the sample rate required by whatever codec is chosen for the DSP's output. For me, that generally means that 48 KHz files get resampled to 44.1 in a way that result in some atrocious artifacts that I think anyone can hear:
- 48 KHz input (https://skew.org/tmp/winamp/aliasing_tests/original_input_48.wav) via standard input plug-ins
- 44.1 KHz output (https://skew.org/tmp/winamp/aliasing_tests/shoutcast_aliased_output_44.mp3) via the SHOUTcast DSP
The FFSoX Player input plug-in resolves this issue. I have it simply resampling always to 44100, and handling all the types of files in my playlist. Since the DSP receives already-resampled audio from the input plug-in, no further resampling is applied, and my stream sounds just fine. Many thanks to Peter for helping me get it working.
Suggestions for improvement: The meaning of "Minimum" and "Multiple" isn't obvious; there should be a tooltip or more descriptive labels explaining what they do. The ReplayGain processor needs to implement clipping prevention. There should be documentation about what file types aren't supported by the FFmpeg DLLs shipped with the plug-in, so you know in advance whether you need to replace them.