Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: mp3DirectCut leaving the original 'length' metadata in edits (Read 4027 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mp3DirectCut leaving the original 'length' metadata in edits

Hi

I'm editing-out the news-and-travel from some mp3 radio shows, using mp3DirectCut (v2.34) (so I don't have to re-encode the mp3s and lose quality).

All is fine & dandy except that in the finished article, foobar2000 (v1.4.6) sees the length/duration as the original (unedited) length. Other players (vlc, MS Groove) and MSExplorer report the correct (edited) length.

How, can I get around this please? I want a method that gives output files with the correct metadata.

I have only just started the project. I don't necessarily need to fix the few that I have already done, (although that would also be nice), I mainly want an effective method of making edited mp3s that show the right length, going forward.

I guess by:
-    using some other settings in mp3DirectCut or
-    manually changing/correcting the length metadata in the final files after the event

---


More background:

3) I believe that the history/ lineage of the files is .ra -> .WAV -> cbr mp3
(some earlier edits were done (WAV) in Cool Edit Pro or Audacity)
Files are CBR mp3, mostly 128kb/s stereo.
[I googled and found some stuff about similar problems being in the VBR header, but these are CBR files]

4) I'm not pro or a programmer, so would prefer an easy/baby-language fix using freeware software, if possible.

5) I would prefer a solution that doesn't lose audio quality through re-encoding.

6) The edits are: topping and tailing the lead-in/out, plus in the middle of the show, 'fade-out/chop/fade-back-in' a few times. I have also experimented with doing each type of those edits individually, but same result.

7) The mp3DirectCut forum is closed!

8) Windows 10 desktop platform

TIA

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #1
Hello BobSter2.

Don't worry. We will figure something out ;).

First, can you please update your foobar2000 to newer version? 1.4.6 is pretty old now.

There are couple of different solutions. The easiest one to try is this:
1. Drag all of your MP3 files into foobar2000.
2. Right click on them and choose "Rebuild MP3 stream"

If that doesn't work, we can fix it using mp3packer/ffmpeg, but that involves using command line.
That could be a little complicated for you. So can you please try the method above first?

Also, it would be really nice if you could upload short problematic sample here. (Up to 30 seconds.)

gold plated toslink fan

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #2
Thanks for the reply, I really appreciate it.  :)

I've now updated to Foobar 1.6.7  and rebuilt the MP3 stream, as-per..

But the problem persists. 

I attach a 3 second sample, (x 2, before and after Rebuilding).  They both think they are 1 hour 57 in Foobar and show as 3 seconds in vlc.

I'm OK using the command line if someone tells me what to type!

thanks

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #3
If you in foobar2000 instead right-click, Utilities -> Fix VBR MP3 header...
then it will show a length of 0:03.567 (157 295 samples).

Quote
[I googled and found some stuff about similar problems being in the VBR header, but these are CBR files]
Don't be surprised if a VBR header says something wrong about a file that isn't even VBR ;-)

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #4
Thanks for sharing the files.

You can do what Porcus said above, it will work, but I think running your files through
mp3packer is better because they have some errors and mp3packer will fix them.



It is kinda hard to find mp3packer online so I will attach both executables below.
All you have to do is drag your MP3 files on mp3packer executable and it will work just fine.
If you already have lots of files you can write a very simple batch script to fully automate it.
gold plated toslink fan

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #5
I don't know what options will be applied upon drag+drop at exe ... it can so happen that mp3packer will ditch broken frames and that could actually sound worse. Also, gapless info could go out of the window, if you want to keep that. For what it is worth, it works best on valid files.

But MP3packer is fun. A bundle with the WinMP3Packer frontend is here: https://web.archive.org/web/20211006214629/http://jaybeee.themixingbowl.org/winmp3packer/WinMP3Packer-1.0.18-alpha-2.04.7z


Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #6
Thanks guys - much appreciated :)

My experience trying these on the full (1 hour 40 min) files is that mp3packer64.exe creates a new file with the old filename suffixed with "-vbr".  It does seem to be a VBR file (the bitrate on the Foobar2000 status bar jumps up and down by +/- 2 kbps as you play it). It is the same if I try it on a brand new mp3 file I just made on Audacity which is 100% definately CBR to start with.

mp3packer64.exe doesn't change the reported length of the file (as-per the OP)  for me - those 3 minute samples I attached still report as 1 hour 57min in Foobar after mp3packering them.  

I haven't noticed any degradation in quality (but they are 1.5 hours long and it will take a while to listen all the way through).

I think I'd rather stick with CBRs, though.  Originally (15 years ago) I had some mp3 players that struggled with vbr, so I have an irrational aversion to it!

Foobar's 'Fix VBR Header' utility fixes the metadata fine and reports the durations as they should be. 

thanks, any further pointers are very welcome

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #7
The wrong length is saved in the tag field "iTunSMPB". It is a proprietary field for Apple. Most other software record the duration of VBR files in a different data structure called a Xing header. Mp3DirectCut just passes this tag field through like others. Technical info has no bussiness being in the tags.

You can use a hex editor to rename this field or an old version of Foobar2000 to remove this data from the Comment, or any other program that allows to do that, for example, Mp3Tag. That is all there is to it. No need to recompress the entire stream.

Don't worry about gapless data in this case because you have intentionally cut a fragment, so the original values are no longer meaningful.

Some frames at the start are always incomplete after cutting because of the bit reservoir. If you place the cut in a quiet section, there won't be any glitch. To avoid this, you need to use MP3packer before processing to increase the bitrate to the maximum, and then compress the file down again. This process is lossless, but that is much work, and takes time.

-b 320
-b 56 -z

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #8
I don't know what options will be applied upon drag+drop at exe ... it can so happen that mp3packer will ditch broken frames and that could actually sound worse. Also, gapless info could go out of the window, if you want to keep that. For what it is worth, it works best on valid files.

But MP3packer is fun. A bundle with the WinMP3Packer frontend is here: https://web.archive.org/web/20211006214629/http://jaybeee.themixingbowl.org/winmp3packer/WinMP3Packer-1.0.18-alpha-2.04.7z


  :P

It's still up at themixingbowl.org: wiki/MP3Packer

-

When I get mp3s that aren't produced by me, I always run through foobar2000: Rebuild MP3 Stream | Optimize file layout + minimize size | Fix VBR MP3 header

That's thus far always resulted in a compliant MP3. But yes, MP3Packer can be used and is a great tool, hence why I continue to host it at tmb.dj

EDIT: just in case someone gets worried about themixingbowl and some ha.io ToS: it's a strictly non-commercial music sharing site. Nothing that can be bought / ever licensed. 99% are DJ mixes.

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #9
jaybeee, I have some problems with your website.
On both the PC (Windows) and Android when using Chrome nothing happens when I left click to download the files.
If I right click and choose "Save link as..." the following message appears:



Sure, I can click "Keep" and it will download the files normally, but most people will think links are dead.

I can see that link posted by Porcus is actually using web archive.
I guess me and Porcus did the same thing.
We both thought links are dead so we used web archive instead.
On Firefox it works normally.
Maybe you can add warning message for Chrome users?
gold plated toslink fan

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #10
Quote from: Markuza97
...
thanks for the report. I've added s to the http: and it now works in Chrome. I have Firefox so didn't notice the issue. Please try again and see if it's ok for you now.

btw it's not my website; I'm one of the long-serving admins there.

 

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #12
....you need to use MP3packer before processing to increase the bitrate to the maximum, and then compress the file down again. ..

-b 320
-b 56 -z

How do I run this please?
 
If I launch the mp3packer64.exe, I get a commandline window saying its v2.04-268; a list of the switches and a blinking cursor, but it doesn't see any text inputs from me.

The GUI version returns :
Processing file xyz.mp3
Skipping CBR file
Finished processing file.

0 Items successfully processed and 1 items copied. 0% decrease in size. 0 items failed.

and no new file is output (output path same as input).

I tried the options: 
2.Convert to CBR in place and
3.Convert to CBR in place (force).
Minimum bitrate 320;
append text: yes.
In the GUI, the Command Line text says -b 320, as expected.

I am trying to change my 64Kb/s CBR source file to 320K, as per the quoted text, above

thanks

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #13
...

I am trying to change my 64Kb/s CBR source file to 320K, as per the quoted text, above

thanks
I think you need to have a read of what Mp3Packer actually does. It can't turn a 64kbps cbr file into a 320kbps file - it doesn't transcode or perform some magic.

With a 64kbps cbr file all you could do is make it a vbr file. But it likely wouldn't change the bitrate at that level (if it does then it would be no more than a handful and completely pointless).

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #14
Ah, OK. 

I just want to make edits to a low-bitrate (~64kb/s) cbr mp3 (using mp3DirectCut) with the minimum of editing artefacts.

I read j7n's comment as saying that the best way to do that is to max-it-up to 320k in mp3packer; do the edits, then wind it back down to 64k again. But I might have misunderstood.  I'm not married to any particular solution.

I get some artefacts doing straight edits of the CBR mp3 in mp3DirectCut.  If there is a way of minimising the artefacts, I'd love to learn about it :)

thanks
(I have no interest in turning anything into VBR)

Re: mp3DirectCut leaving the original 'length' metadata in edits

Reply #15
A cutter should be overlapping the cuts and using LAME headers to splice off the extra data, which still needs to be decoded to fill the bit reservoir prior to the start of the wanted cut point. Luckily, LAME headers allow quite a bit of splicing, up to about 8 packets or so worth of samples. Usually the maximum dependency is about 2 extra packets, but a splicer should be able to determine this when it is doing the cutting.