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.
Recent Posts
13
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Eurobeat_fan -
Quote from: maikmerten on
just like Eurobeat_fan's "Not a good choice for 320kbps CBR" (at such bitrates I expect "usually transparent" results)
What I meant about calling it an inferior choice is that it doesn't really utilize the bitrate it has in CBR 320 kbps. It continues to show its typical differences from LAME (sticking to mid-side stereo instead of true stereo most of the time, using sfb21 less often), and it leads to the fact that it almost never uses bit reservoir to its full potential. I have only seen Helix using 150 bytes out of 511 for any block possible but never the whole 511 byte, not for a single transient. This means that at 320 kbps we just waste bits for nothing, the bitrate is excessive to the psy-model that Helix utilizes and it can do just fine with, let's say, 224 kbps CBR. It may be not a problem in general but I'm pretty sure that Helix will fail on more samples than LAME does at 320 kbps simply because LAME has more ideas about what information to save into a 320 kbps file.

I don't have any complains about VBR mode in that regard (obviously).
15
3rd Party Plugins - (fb2k) / Re: foo_wave_seekbar
Last post by Zao -
I'm still a bit confused - as whenever you open a media file with an embedded or external cue sheet, foobar2000 should split it up into separate virtual tracks according to the sheet.
I am not aware of any situation where you can get it to open the file as-is without processing the sheet.

Could you describe your workflow in which such a thing happens?
I'll probably not get around to doing such a feature in this phase of the project but I'd like to understand the problem.
16
CD Hardware/Software / Re: Should I fix offsets even if ripped correctly
Last post by korth -
It is a matter of preference.
AccurateRip ignores the first 2939 and the last 2940 samples of the CD Image.

a) keep it
  • If the rip verifies as accurate even at a different offset, it is accurate, why change it?
  • Fixing the offset will delete samples from one end of the Image and pad null samples to the other
  • If you fix the offset the CRC32 hashes for Image/Tracks will be different than those shown in the extraction log
b) fix it
  • Fixing the offset will remove/pad less than 0.02 seconds of audio (667 samples) from an area of the first/last track that is probably inaudible anyway
  • AccurateRip may show higher numbers at the new offset
19
3rd Party Plugins - (fb2k) / Re: Can/How foo_musicbrainz write Picard Musicbrainz Tags ?
Last post by marc2k3 -
foo_musicbrainz was never meant to write tags that are compatible with other apps. You should use Picard for that.

Here's an excerpt from the docs I wrote when I spent a short time maintaining it....

Quote
### Tag Mapping

Before you consider using this to tag your files, it's important to note that it does
not strictly adhere to the `Picard` tag mappings as documented [here](https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html).

If compatibility with `MusicBrainz Picard` or other taggers/players that make use of `MBID` data is
more important then you should probably avoid using this. More details of what this component
does and why can be found [below](#the-nerdy-stuff).

### The Nerdy Stuff

When it comes to tagging `MBID`s, this component always follows the naming conventions used for `Vorbis`
comments regardless of the underlying file format/tagging sheme.

For example, it will write `MUSICBRAINZ_ARTISTID` instead of `MUSICBRAINZ ARTIST ID` to `MP3` and `M4A` files.
Repeat that for all tags prefixed with `MUSICBRAINZ`.

The following differences affect `ID3` tagging only:

- `DISCSUBTITLE` is written to `TXXX:DISCSUBTITLE` rather than `TSST (SET SUBTITLE)`
- `LABEL` is written to `TXXX:LABEL` rather than `TPUB (PUBLISHER)`
- `MEDIA` is written to `TXXX:MEDIA` rather than `TMED (MEDIA TYPE)`
- `MUSICBRAINZ_RECORDINGID` is written to `TXXX:MUSICBRAINZ_TRACKID` rather than `UFID://musicbrainz.org`
- `RELEASECOUNTRY` is written to `TXXX:RELEASECOUNTRY` rather than `TXXX:MUSICBRAINZ ALBUM RELEASE COUNTRY`
- `PERFORMER` is written to `TXXX:PERFORMER` rather than `TMCL` / `IPLS`

The whole purpose of this is to unify tag display/search across `foobar2000` regardless of file format.
It's easier to search for `%LABEL% IS blah` rather than `%LABEL% IS blah OR %PUBLISHER% is blah` which
is what you'd have to do if this was `Picard` compatible.
20
CD Hardware/Software / Should I fix offsets even if ripped correctly
Last post by michaelq -
I have a few CDs from non-famous artists. Some have 1 or 2 entries in the AccurateRip database. And those entries are agree with my rips with an offset of e.g. 667 samples. I am sure my drive offset is set correctly. Now, I suspect there are two reasons:

1. this user did not set their offset correctly (it happens with more famous CD, too, but 1 or 2 incorrect offsets don't matter compared to 200 correct ones)
2. those bands with their low-budget production simply burn the CDs with private CD players which have different offsets which don't agree. We could call that a different "pressing".

My question: Should I (a) keep the FLAC file from my CD as it is or (b) fix the offset by 667 samples to match the one entry in the database.

This is probably a matter of taste but do you have any recommendations or reasons for (a) or (b)?

Best, Michael