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: No Monkey Audio support in fb2k beta 13 ! (Read 8259 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

No Monkey Audio support in fb2k beta 13 !

I was using beta12 and NEVER had issues with playing/converting to/from
Monkey Audio APE files. So I'm confused, I just upgraded to beta 13, besides
that installation erased all my previous components, the in_foo_ape.dll plays,
but if CUESHEET is embedded into a file, foobar crashes. Also pressing "STOP"
button causes an error. Everything was just working, now it is broken.
In past 3 weeks I completely remastered my APE images and embedded CUESHEETs
in them, now I can't even switch to FLAC, because of new conception of Peter...
I cannot find old beta 12 dll's to make conversion to FLAC, because on www
are only new beta13 components. I suppose I'm not the only one angry with that
situation. I prefer APE, because it's very good compromise betweeen filesize
and speed of coding/decoding. FLAC files are ALWAYS bigger  Even about 20-50 MB!
So, please, can anyone send me or point me to DLLs compatible with beta 12,
as typed: columns UI and freedb tagger.
Or, give me solution, about how to get fb2k to work with APE's with CUEs embedded...

Anyway, Happy X-mas for everyone 

No Monkey Audio support in fb2k beta 13 !

Reply #1 –
In english please.
I am arrogant and I can afford it because I deliver.

No Monkey Audio support in fb2k beta 13 !

Reply #2 –
Quote
In english please.
[a href="index.php?act=findpost&pid=352183"][{POST_SNAPBACK}][/a]


I'm not native speaker.
In other words:
Monkey Audio support in fb2k v0.9 beta 13 is broken.
Peter claims that Monkey Audio library is no more maintained.
But, I had never such a problems with Monkey Audio support, in earlier betas.
So, the problem IS: if cue sheet is embedded into APE file, foobar beta 13 crashes.
With the same library that was used in beta 12, I think.
I have over 200 CD's , with embedded cue sheet, I spent last 3 weeks doing this,
and recompressing all to 'High' level of compression, now in beta 13 I can't
even play them or convert them to other format... AND - I can't revert to beta 12,
because beta 13 erased old components, and on the internet there are no beta 12
compatible components anymore... -> Columns UI and freedb tagger.
Do you unterstand now, or still not?   

No Monkey Audio support in fb2k beta 13 !

Reply #4 –
You could always install version 0.8.3 and use it to convert your files.  I believe the special installer has all the components you would need.

No Monkey Audio support in fb2k beta 13 !

Reply #5 –
Quote
So, the problem IS: if cue sheet is embedded into APE file, foobar beta 13 crashes.

I tested this and had no such crash.  Monkey's Audio 3.99, Extra High compression.
I'm on a horse.

No Monkey Audio support in fb2k beta 13 !

Reply #6 –
Quote
Quote
So, the problem IS: if cue sheet is embedded into APE file, foobar beta 13 crashes.

I tested this and had no such crash.  Monkey's Audio 3.99, Extra High compression.
[a href="index.php?act=findpost&pid=352205"][{POST_SNAPBACK}][/a]


i'm not sure if the monkey's audio frontend supports cuesheets, but otherwise you might just use that to convert everything to something else with (if it indeed is broken and not just a freak occurrence)..
however, on my pc it doesn't crash either...

No Monkey Audio support in fb2k beta 13 !

Reply #7 –
Quote
Quote
So, the problem IS: if cue sheet is embedded into APE file, foobar beta 13 crashes.

I tested this and had no such crash.  Monkey's Audio 3.99, Extra High compression.
[a href="index.php?act=findpost&pid=352205"][{POST_SNAPBACK}][/a]


Maybe I'm doing some things wrong... I deinstalled fb2k completely,
and then installed clean beta 13 install, next installed the library for APE
files, then I tried to load set of APE files with cuesheets embedded.
fb2k generated an error. I don't know if I can ask Peter for help, in case
he maybe have no time for me even if I can speak to him in my national
language, so I'm using this hydrogenaudio list to describe my problems...
I'll try it again, will describe if got luck or not 

No Monkey Audio support in fb2k beta 13 !

Reply #8 –
Post the error you are getting.
You can open the console and copy/paste I'd think.

No Monkey Audio support in fb2k beta 13 !

Reply #9 –
Quote
Monkey's Audio decoding support download link

This component has known stability issues (random crashes during decoding). Since problematic library appears to be no longer maintained, we recommend using another lossless format instead.

I suppose "problematic library appears to be no longer maintained" means the foobar component. Monkey's Audio has not changed to more problematic. Monkey's Audio support (ape/ape+cue/ape+apl) works perfectly with foobar 0.83.

If 0.9 has problems with Monkey's Audio format I seriously hope the problems can be fixed. I have ripped about 2000 audio CDs in this format:
Monkey's Audio source file (disc image) + CUE (in unaltered EAC format) + APL track link files (for complete tagging including the replay gain info).

I have no intention or desire to convert my file archive. Personally, I have no use for embedded cue sheets, but I think they should be usable with any compression format similarly like separate cue sheets.

Please....
 

No Monkey Audio support in fb2k beta 13 !

Reply #10 –
Quote
I suppose "problematic library appears to be no longer maintained" means the foobar component. Monkey's Audio has not changed to more problematic. Monkey's Audio support (ape/ape+cue/ape+apl) works perfectly with foobar 0.83.
[a href="index.php?act=findpost&pid=357782"][{POST_SNAPBACK}][/a]
All recent crash reports related to Monkey's Audio support pointed to their code not ours. Only difference is that 0.8.3 APE input contains hackfix for maclib APE tag reader security hole which also happens to axe a few other problems; reverting to unmodified maclib 3.99 while trying to workaround something else caused "new" problem with APE tag reader to appear - while all other apps using unmodified maclib 3.99 suffer from exact same problem, including original frontend (haven't tested 4.01).
There's still one apparently random crash in decoder itself (reading past allocated buffer in CUnBitArray); we currently suspect that the problem somehow appeared with new compiler (0.8.3 is MSVC6, 0.9 is MSVC8) but rebuilding APE input with older compiler is not an option as current 0.9 SDK doesn't even compile on pre-MSVC8.
Microsoft Windows: We can't script here, this is bat country.

No Monkey Audio support in fb2k beta 13 !

Reply #11 –
Quote
I have no intention or desire to convert my file archive. Personally, I have no use for embedded cue sheets, but I think they should be usable with any compression format similarly like separate cue sheets.[a href="index.php?act=findpost&pid=357782"][{POST_SNAPBACK}][/a]

It does not make sense to embed cuesheets in state-of-the-art (container) formats that natively support chapters, in fact it is likely to conflict with this. This means that support for embedded cue sheets will only be enabled for selected formats. (There is generic code in the SDK for enabling support for embedded cue sheets to ensure consistent behaviour for all formats that do support it.)
External cue sheets on the other hand are handled by a generic cue sheet input that delegates decoding to whichever format the referenced audio data is in. The cue sheet input does not check the format of the referenced data, and thus gives the user the freedom to (ab)use external cue sheets with any format he or she desires.

No Monkey Audio support in fb2k beta 13 !

Reply #12 –
Quote
All recent crash reports related to Monkey's Audio support pointed to their code not ours. Only difference is that 0.8.3 APE input contains hackfix for maclib APE tag reader security hole which also happens to axe a few other problems; reverting to unmodified maclib 3.99 while trying to workaround something else caused "new" problem with APE tag reader to appear - while all other apps using unmodified maclib 3.99 suffer from exact same problem, including original frontend (haven't tested 4.01).
There's still one apparently random crash in decoder itself (reading past allocated buffer in CUnBitArray); we currently suspect that the problem somehow appeared with new compiler (0.8.3 is MSVC6, 0.9 is MSVC8) but rebuilding APE input with older compiler is not an option as current 0.9 SDK doesn't even compile on pre-MSVC8.[a href="index.php?act=findpost&pid=357807"][{POST_SNAPBACK}][/a]

I am not a programmer, but I think I understand what you mean. So far I am safe with my file archive because I can use older tools for it. I don't keep my disc image files on-line anyway. I have instead separate track files for my day-to-day needs.

Perhaps I could try to ask Matt's opinion on this matter, since he has shown some Monkey's Audio activity recently.

No Monkey Audio support in fb2k beta 13 !

Reply #13 –
Quote
It does not make sense to embed cuesheets in state-of-the-art (container) formats that natively support chapters, in fact it is likely to conflict with this. This means that support for embedded cue sheets will only be enabled for selected formats. (There is generic code in the SDK for enabling support for embedded cue sheets to ensure consistent behaviour for all formats that do support it.)
External cue sheets on the other hand are handled by a generic cue sheet input that delegates decoding to whichever format the referenced audio data is in. The cue sheet input does not check the format of the referenced data, and thus gives the user the freedom to (ab)use external cue sheets with any format he or she desires.[{POST_SNAPBACK}][/a]

So the embedded cue sheet system is a bit more complicated than just a copy of the cue file inside the file tag area. I didn't know that. I just meant that the seek points should be usable with any file encoding format like they seem to be with v. 0.83. and external cue files.

Containers are a different thing. Actually, I would very much prefer playable Matroska container files instead of the "rar container" system I use currently. My typical album archive looks like this:

[a href="http://kotisivu.mtv3.fi/alexb/pix/package.png][/url]
Click to enlarge.

If I have understood correctly the Matroska format supports auxiliary files. So at least in theory it should be possible to convert my album archives including the cue, log and cover art files to Matroska format.

[span style='font-size:7pt;line-height:100%']Edit: a small fix[/span]