Duration misreported and seek errors in re-encoded mp3; WinFF (MS Windows) v.1.5.3

[safeas.milk]

As usual I'm not quite sure if this is a WinFF issue or an issue with the latest bundled Windows version of ffmpeg, so if the latter, if one of the developers here can give me the suitable url, I will raise there.

Under XP SP3 (still - I know).

I listen to a lot of podcasts in mp3 format but many are ridiculously sized from having excessive bitrate/sample rate etc applied to speech which are only really needed for music. So to save space I re-encode them down to something more suitable like typically  CBR, 22.5kHz, mono, 32kbps.

Take any number of test files (at least over 30-40minutes - don't recall downsizing shorter ones) with either cbr or vbr and after downsizing by reducing bitrate etc their duration is misreported and seek errors beyond phantom (misreported) end of file occur.

Occurs with WinFF v.1.5.3 but noticed beginning (?) with v. 1.5.1.

Example:
http://www.financialsensenewshour.com/broadcast/fsn2014-0517-1.mp3

Converting to lower cbr and Hz /kbps results in file duration misreporting (typically duration is stated to be much less than known actual from original) and seek errors in the unreported part (always the end so far, nothing dropped from beginning).
e.g. this example mp3 is misreported in iPod Nano 8gb after re-encoding as about 30m instead of 53m appx.  Also misreported in MP3DirectCut.

Arguments employed:
-acodec libmp3lame -ab 32k -ac 1 -ar 22050

After noticing the error I then tried fixing output of WinFF using VBRfix gpl version 1 beta but that seems to introduce new seek errors tho it fixed duration reporting.

Also tried MP3Utility Version 1.80b which reports

"Error: Sync error reading frame header 3 expected at byte 124,500.  Approx. time: 0:00 (0.0% through audio).
Previous valid frame header located at byte 124,344.
Resync failed (no matching frame header found within 2,000 bytes).

Summary: 2 total frames processed (0 padded, 2 unpadded).  Bitrate is constant."

Anyone else? Causes? WinFF or ffmpeg Windows versons?

tia

[Ian Stoffberg]

Hi,

As you already probably guessed, it's probably ffmpeg.

Winff literally builds a command line and passes it to WINFF.  You can probably try and fix the problem by taking the output generated by WINFF and tweaking the command line until you get a satisfactory result.

Let us know if our presets need some work or contribute your resulting podcast shrinker as a preset to include in future releases!

Cheers,

Ian

--
You received this message because you are subscribed to the Google Groups "WinFF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winff+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[BiggMatt]

​You can upgrade or downgrade the ffmpeg​ included with winff by a little handy work (no command line). I would try the newest, first. If it still happens, a version prior to 1.5.1

To start download one of these 2 files:

for 32 bit:

http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20140519-git-76191c0-win32-static.7z

for 64 bit:

http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20140519-git-76191c0-win64-static.7z

Then extract the .7z file to the desktop. You may need to get the 7zip program but most other achievers such as winzip and winrar will extract them too.

open the ffmpeg folder and then the bin folder

select all and copy the three files, ffmpeg.exe, ffplay.exe, ffprobe.exe

open mycomputer and the select the C: drive

open program files, and then winff

paste the files into the winff folder and it will replace the old ones.

try  converting again the podcast agin. That usually does it. 

If not you can try an older version of ffmpeg that didn't do it. You said it started in 1.5.1, we can try the versions prior to 1.5.1. Winff 1.5.0 came out December 2012.

Here is 32 bit:

http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20121230-git-518239c-win32-static.7z

Here is 64 bit:

http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121230-git-518239c-win64-static.7z

Then just repeat the steps above for these files.

fore more versions of ffmpeg go to:

http://ffmpeg.zeranoe.com/builds/

and sele

[safeas.milk]

Thanks for the replies.

I did try one or two earlier ffmpeg versions but no change.

The situation is currently unclear, what I can say is:

1. on re-examination the WinFF output's duration is generally correctly reported when played in MP3DirectCut. 
2. conversely, it usually isn't reported right when played on the iPod 8GB Nano, mp3 files loaded using Apple iTunes and drag and drop from Mp3tag (Florian Heidenreich) and iirc also whrn dragged from e.g. Windows Explorer. Result is not just misreporting but inability to manually seek back or forward once the (wrongly reported) "end" of the mp3 file has been reached.
3. also oddly, but said Mp3tag  (v.2.59a, 2014-04-20 likewise wrongly reports the duration of the ouput mp3 files, e.g. one is shown as 20m whereas when played in MP3DirectCut it is about 1h10m.  Wondering if this misreporting 'taints' the file particulars as fed to iTunes so the latter misreports...
4. not sure, but duration misreporting may have occurred after updating iTunes to v.11.1.4.62.
5. I just retried re-(trans)encoding http://www.financialsensenewshour.com/broadcast/fsn2014-0712-1.mp3 in WinFF using -acodec libmp3lame -ab 32k -ac 1 -ar 22050 and the output was blank.  This has occurred occasionally with other mp3 files from various sources and again I havenl't observed enought to guess what's up.  However the re-(transcoding) works when the subject mp3 is fed to e.g. Freemake audio converter or the audio converter element in Video to Video Converter v.2.9

So an inconclusive potentially time-consuming mess at present.  But if anyone has a url for the primary ffmpeg developer's site pls post it and I may review activity there for similar reports.  tia

[safeas.milk]

EDIT:

I mentioned that WinFF had just produced a blank output file i.e. no audio discernible.  So I just re-(trans)coded that source mp3 using Video to Video Converter and viewing its ouput mp3 in Mp2tag I noticed again the converted file's duration was misreported. V2V like WinFF was set to output CBR 22Hz 16kbps mono but Mp3tag reports file as 48kbits CBR 22Hz and only 20m instead of 1hr.  This looked suspicious so I ran that output through VbrfixGui* and it output the new file as 22Hz 16kbps VBR, with the duration CORRECTLY reported.
Not sure what to make of all this still but surely a vbr input file should be converted to CBR if command line is so set?  Anyway this tends to suggest the fault is not with iTunes or Mp3tag although where exactly it might be is unclear and in either case of this specific converted mp3 file MP3DirectCut reports the duration CORRECTLY both before and after VbrFixGui is applied!  So far, looking at other forum queries finds only someone suggesting to add to ffmpeg "-minrate 96" or some other deisred rate to ensure ouput as CBR not VBR.  Pass - feelin' fazed.


* http://www.thefreewindows.com/91/fix-mp3-files-that-report-wrong-time-length/

[safeas.milk]

Memo to self (and anyone else who has encountered this oddity):

Chanced upon a solution in the form of the aged but effective ID3Remover v.1.2

https://sourceforge.net/projects/id3remover/

- this zaps all tag fields including some which appear to be invisible several other mp3 utilities including MP3Tag's 'Extended Tags' menu and has been effective where mp3val and others have not fixed. After it removes all tags, add new ones to taste and re-load edited mp3 to iPod - latest this worked on was previously misreported as 1hr and after passing through ID3Remover v.1.2 correctly reported its length as 30m.

On Monday, 19 May 2014 15:02:28 UTC+1, safeas.milk wrote:

[Ian Stoffberg]

Good tip.

--

You received this message because you are subscribed to the Google Groups "WinFF" group.

To unsubscribe from this group and stop receiving emails from it, send an email to winff+unsubscribe@googlegroups.com.