mpg123-devel

[mpg123-devel] Notion of SEEK_END

[Thomas B. <to...@tr...>]

Hi, I'm puzzled with mpg123_seek() when using SEEK_END.
To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
overshoots by 10 samples (length + 10). On the other hand, seek(10, 
SEEK_END) will go to 10 samples before the end. I think this notion is 
inverse to other uses of SEEK_END. Is it the expected behaviour? Unless 
I haven't overlooked something fundamental and my test is wrong, it 
should eventually be mentioned in the docs.
Greetings
Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

Am Tue, 29 Aug 2023 17:21:23 +0000
schrieb Thomas Brand <to...@tr...>: 

> To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
> overshoots by 10 samples (length + 10). On the other hand, seek(10, 
> SEEK_END) will go to 10 samples before the end. I think this notion is 
> inverse to other uses of SEEK_END.

Oh, great. Looking at lseek(2) and at my own documentation in mpg123.h,
the behaviour indeed does not match the description. It's utterly
wrong and you are the first person to notice.

Damn. I have to think hard on how to best handle it. Just correcting
the behaviour would break anyone relying on the existing. At the same
time, precisely because you're the first one noticing, I _guess_ that
you might be the only one trying to seek from the end on MPEG files so
far.

Having the reverse meaning compared to lseek really sucks. I don't have
the solution right now for the next release, just a confirmation that
you're right.


Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

[on-list again, again]

Am 30. August 2023 23:11:34 MESZ schrieb Thomas Brand <to...@tr...>:

>>> Eventually a "seek_compatibility" flag could be introduced.  
>> 
>> This would need to be opt-in, though. We could introduce a flag
>> to fix SEEK_END behaviour. Or we could just document the state as-is
>> and realize that it's a rare case with not much practical impact.
>>   
>it's a hard decision. i don't know what's the best future-proof approach here.
>opt-in sounds good, plus documentation ..  

>> Hm. Returning an error or silently (only by return value) limiting offset
>> to the end. Both may make sense.  

I think it's simple after all. In a read-write library, seeking beyond
the end makes sense. You can write there and enlarge the file.
In a read-only library, only positions within the file make sense.

Current mpg123 inverts the sign of an offset from SEEK_END,
as I thought back then that it would be obvious to mean positive
steps from the end back. Only one direction does make sense.

So, what's the problem if I'd just ignore the sign of the SEEK_END
argument?

  mpg123_seek(mh, 128, SEEK_END)
  mpg123_seek(mh, -128, SEEK_END)

could both do the same thing. The latter would've been a error
with current libmpg123. Turning errors into valid behaviour has
its risks, but in this case, I think it is sensible.  


Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

Am Sat, 2 Sep 2023 15:28:01 +0200
schrieb Thomas Orgis <tho...@or...>: 

>   mpg123_seek(mh, 128, SEEK_END)
>   mpg123_seek(mh, -128, SEEK_END)
> 
> could both do the same thing. The latter would've been a error
> with current libmpg123. Turning errors into valid behaviour has
> its risks, but in this case, I think it is sensible.  

May you verify if current trunk (or snapshot) apply this correctly?

See updated https://mpg123.org/api/group__mpg123__seek.shtml .


Alrighty then,

Thomas